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PREFACE 


This  report  was  prepared  by  The  BDM  Corporation,  Technology  Appli¬ 
cations  Center,  1801  Randolph  Rd  SE,  Albuquerque,  New  Mexico  87106  under 
the  Defense  Nuclear  Agency  Contract  Number  DNA001-78-C-0194.  Lt,.  Col .  L. 
A.  Darda  is  the  Contracting  Officer'  Representative. 

This  report  presents  the  status  of  the  Engineering  Development 
2 

phase  for  the  TNF  S  Instrumentation  Development  effort.  This  instrumen¬ 
tation  is  needed  to  satisfy  the  test  analysis  and  evaluation  requirements 
of  force-on-force,  free-play  testing  of  the  TNF  using  real-time  casualty 
assessment.  The  instrumentation  design  philosophy  centered  around  a 
system  that  is  to  be  modular,  flexible,  and  expandable.  The  instrumen¬ 
tation  will  be  portable,  will  not  require  extensive  field  support,  and 
in  some  cases  will  be  secure  from  outside  monitoring.  Existing,  off- 
the-shelf  technology  is  being  used  to  minimize  development  risk. 

The  instrumentation  system  consists  of  three  basic  elements.  The 
master  station  performs  the  operations  and  maintenance,  calibration, 
test  control,  and  data  quick-look  tasks.  The  RF  communications  system 
allows  for  two-way  communications  from  the  master  station  via  repeaters 
to  the  players,  and  will  evolve  into  an  accurate  transponder  position 
location  subsystem.  The  player  instrumentation  contains  a  microcomputer 
and  will  be  capable  of  totally  decentralized  operations.  It  will  perform 
the  functions  of  position  location,  weapon  simulation  (weapon  and  target 
sensors) ,  player  cueing,  data  logging,  RF  communications  with  the  master 
station,  and  the  computation  of  real-time  casualty  assessments. 


I 


TABLE  OF  CONTENTS 


Section  Page 

PREFACE  1 

TABLE  OF  CONTENTS  2 

LIST  OF  ILLUSTRATIONS  5 

I  EXECUTIVE  SUMMARY  7 

1-1  INTRODUCTION  7 

2 

1-1.1  The  Requirements  for  TNF  S 

Instrumentation  7 

1-1.2  Results  of  the  FY  1978  Instrumentation 

Study  Effort  11 

1-1.3  Scope  of  the  FY  1979  Instrumentation 

Development  Effort  13 

1- 1.4  TNF  S^  Instrumentation  System  Design 

Philosophy  14 

1-1.4. 1  Player  Pack  15 

1-1. 4. 2  Master  Station  17 

1-1. 4. 3  Communications  System  21 

1-2  INSTRUMENTATION  DEVELOPMENT  SYSTEM  24 

1- 3  TNF  S2  INSTRUMENTATION  SUMMARY  25 

II  FUNCTIONAL  ELEMENT  DEVELOPMENT  STATUS  28 

2- 1  INTRODUCTION  28 

2- 1.1  Scope  of  the  FY  1979  Development 

Effort  28 

2-1.2  Player  Pack  Development  28 

2-2  EXECUTIVE  CONTROL  SYSTEM  MICROCOMPUTER  30 

2-2.1  Central  Processing  Unit  30 

2-2.2  Programmable  Systems  Interface  31 

2-3  MEMORY  SUBSYSTEM  35 

2-3.1  Storage  Memory  Subsystem  35 

2-3.2  Main  Memory  Subsystem  37 

2-3.3  Bubble  Memory  Devices  39 


2 


j 

i 


| 


\ 


Table  of  Contents  (Continued) 


Section  Page 


2-4  DATA  LOGGING  SUBSYSTEM  43 

2-4.1  Data  Storage  Medium  43 

2-4.2  Data  Storage  Controller  46 

2-4.3  Data  Storage  Buffer  46 

2-5  UNIVERSAL  I/O  SUBSYSTEM  47 

2-6  BATTERY  PACK  51 

2-6.1  Design  Evaluation  51 

2-6.2  Test  and  Evaluation  Program  52 

2-6.3  Battery  Tester  Functional  Description  53 

2-6.4  Voltage  and  Current  Regulators 

Functional  Description  55 


( 


I 

|  i 

1 1 
•  i 


i 


2-7  RF  SUBSYSTEM  58 

2-7.1  RF  Communication  Subsystem  Function  58 

2-7. 1.1  RF  Message  Duration  60 

2-7. 1.2  System  Load  Due  to  RF 

Message  Traffic  60 

2-7.2  Transponder  Position  Location  Subsystem  61 

2-7.3  Direct  Ranging  Subsystem  63 

2-8  WEAPONS  EFFECTS  SUBSYSTEM  64 

2-8.1  System  Operation  64 

2-8.2  Unique  Characteristics  66 

2-9  PACKAGING  69 

2-9.1  Player  Pack  Units  69 

2-9.2  Repeater  Stations  72 

2- 9.3  Repeater/Transponder  Towers  72 

2- 10  MASTER  STATION  DESIGN  74 

III  SOFTWARE  DEVELOPMENT  79 

3- 1  INTRODUCTION  79 

3- 1.1  Master  Station  79 

3-1.2  Player  Software  81 


3 


Table  of  Contents  (Continued) 

Section  Page 

3-1. 2.1  The  Task  Scheduler  83 

3-1. 2. 2  Memory  Management  83 

3-1. 2. 3  The  Input/Output  Supervisor  83 

3-1. 2.4  Task  Control  Supervisor  83 

3-1. 2. 5  File  Management  84 

3-2  TASK  SOFTWARE  84 

3-2.1  Real  Time  Casualty  Assessment  84 

3-2.1. 1  Direct  Fire  RTCA  84 

3-2.1. 2  Indirect  Fire  RTCA  86 

3-2. 1.3  Position  Location  86 

3-2. 1.4  RF  Communications  86 

3- 3  DEVICE  SERVICE  ROUTINES  (DSR)  86 

IV  INSTRUMENTATION  DEVELOPMENT  PLAN  87 

4-1  INTRODUCTION  87 

4-2  DEVELOPMENT  SCHEDULE  AND  TASKS  88 

4-3  RELATED  EFFORTS  FOR  FUTURE  PLANNING  88 

4- 3.1  Continued  Development  91 

4-3.2  Issue-related  Instrumentation  91 

4-3.3  Field  Test  Support  91 

4-4  DEPOT  MAINTENANCE  93 

V  REFERENCES  94 

APPENDIX 

A  GLOSSARY  97 


4 


LIST  OF  ILLUSTRATIONS 


Figure 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 


Page 


LORAN-C  decentralized  system  16 

Player  instrumentation  utilizing  LORAN-C  for  position 
location  18 

2 

TNF  S  prototype  player  pack  configuration  19 

Master  station  deployment  20 

Repeater/transponder  23 

Instrumentation  elements  and  developer  26 

2 

TNF  S  instrumentation  development  master  schedule  27 

ESC  microcomputer  board  diagram,  phase  I  32 

ESC  microcomputer  board  block  diagram,  phase  II  33 

Storage  memory  system  functional  block  diagram  36 

EPROM  board  38 

RAM  board  functional  block  diagram  40 

RAM  board  41 

Block  diagram  of  data  logging  subsystem  44 

Data  logger  unit  45 

Block  diagram  of  Universal  I/O  48 

Universal  I/O  board  49 

Battery  cell  tester  function  54 

Power  supply  block  diagram  56 

Transponder  position  location  system  62 

Weapons  effect  subsystem  elements  68 

2 

TNF  S  prototype  player  pack  for  footsoldiers  70 

2 

TNF  S  prototype  player  pack  configuration  71 

Repeater  tower  73 

Operations  and  maintenance  trailer  76 

Master  station  support  van  77 

Master  station  deployment  78 

Master  station  controller  80 


5 


LIST  OF  ILLUSTRATIONS  (Concluded) 


Figure  Page 

29  Executive  control  system  architectural  overview  82 

30  Task  communication  paths.  Tasks  request  service 

via  supervisor  calls  85 

2 

31  TNF  S  instrumentation  development  master  schedule  89 

32  Key  1980  milestones  90 

33  Typical  instrumentation  personnel  utilization  92 


M 


6 


SECTION  I 
EXECUTIVE  SUMMARY 


1-1  INTRODUCTION. 

2 

1-1.1  The  Requirement  for  TNF  S  Instrumentation. 

The  Defense  Nuclear  Agency  was  directed  by  the  Secretary  of 

Defense  in  January,  1977  to  implement  the  Theater  Nuclear  Force  Survi- 

2 

vability  and  Security  (TNF  S  )  program.  The  primary  objective  was  to 
"establish  a  broad  technological  program  that  will  allow  decisions  to  be 
made  on  issues  surrounding  the  survivability  and  security  without  degra¬ 
dation  of  the  resultant  effectiveness  of  the  theater  nuclear  weapons  and 
their  delivery  systems."  DNA  was  directed  to  accomplish  this  objective 
by  utilizing,  to  the  maximum  degree  possible,  systematic  investigations 
based  on  realistic  operational  test  data. 

The  scoping  phase,  which  was  accomplished  in  1977,  concluded 
that  an  instrumentation  system  would  be  required  to  gather  the  data 

2 

necessary  to  evaluate  both  the  current  survivability  and  security  (S  ) 
of  the  theater  nuclear  force  (TNF)  and  the  effectiveness  of  proposed 
improvements.  Specific  guidelines  for  the  required  instrumentation  were 
given  as  follows: 

1.  Affordability  —  the  instrumentation  development  and  initial 

procurement  must  not  be  significant  in  relation  to  the  overall 
2 

TNF  S  program. 

2.  Cost  of  Operation  —  the  set-up  time,  facilities,  and  operations 
personnel  costs  must  be  minimized. 

3.  Maintenance  and  Logistics  —  the  instrumentation  must  be 
easily  maintained  (built-in  test  capability)  and  easily  trans¬ 
ported  to  test  sites  in  CONUS  and  Europe. 

4.  Useful  Lifetime  —  the  useful  lifetime  of  the  instrumentation 

2 

must  exceed  the  duration  of  the  5-year  TNF  S  program. 


7 


5. 


f  JJW  MM  HU. 


Flexible  —  the  instrumentation  must  operate  in  all  types  of 
terrain,  accommodate  many  different  player  types  (men,  vehicles, 
aircraft)  and  weapon  types,  and  accommodate  variable  player 
types. 

Furthermore,  the  scoping  effort  identified  the  need  for  free- 

play,  force-on-force  test  scenarios  using  real-time  casualty  assessment 

as  the  primary  procedure  for  gathering  the  data  relevant  to  an  appropriate 

2 

analytical  assessment  of  the  improvements  to  the  S  posture  of  the  TNF. 

Examination  of  the  issues  supplied  by  USAFE,  in  conjunction 
with  the  Early  Test  Capability  and  Instrumentation  Study  efforts  (both 
FY  1978  tasks) ,  allowed  the  development  of  a  spectrum  of  test  scenarios 
with  the  following  characteristics: 

1.  The  number  of  players  (to  include  fixed  objects)  is  typically 
30  to  50,  with  an  occasional  requirement  of  100. 

2.  The  typical  playing  area  is  several  hundred  meters  (300  by  300 
meters),  with  a  maximum  area  of  2  by  2  kilometers.  The  convoy 
exercise  will  require  a  longer  but  narrower  playing  area. 

3.  Most  scenarios  have  elements  of  close-in  interactions  involving 
participants  at  3  to  10  meters. 

A.  The  weapons  systems  employed  are  primarily  portable  by  man  or 
light  vehicle. 

5.  The  instrumentation  must  function  both  in  day  and  night  oper¬ 
ations  in  adverse  weather,  and  over  hilly  and  forested  terrain. 

2 

The  data  requirements  developed  for  TNF  S  testing  are  summar¬ 
ized  in  Table  1.  This  table  presents  the  type  of  data,  the  type  of 
analysis  for  which  it  is  needed,  the  required/desired  accuracy  for  such 
analysis,  and  the  instrumentation  system  which  provides  the  necessary 
information. 

The  Instrumentation  Study  effort  performed  in  1978  concluded 
that  the  force-on-force  test  instrumentation  which  is  presently  being 
utilized  is  first-generation  equipment.  It  was  designed  in  the  1960's 
prior  to  the  existence  of  well-proven  large-scale  integrated  circuitry. 
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TABLE  1.  TNF  S  DATA  REQUIREMENTS 


Hand  Grenade/Explosives  Accurate  Player  Position 

Player  Cueing 


- 


Consequently,  its  operational  and  design  characteristics  reflect  the 
capabilities  and  limitations  of  the  then- available  technology.  Many  of 
the  previously  accepted  operating  procedures  and  instrumentation  tech¬ 
nologies  are  now  considered  as  severe  limitations. 

Today's  force-on-force  instrumentation  has  the  following 
limitations: 

1.  Catastrophic  Failure  Modes 

2.  Complex  Software 

3.  Telemetry  Dependent 

4.  Resource  Intensive 

5.  Limited  Mobility 

The  equipment  currently  fielded,  in  all  cases,  is  completely 
dependent  upon  a  central  computer  system  which  tracks  all  of  the  players 
and  scores  all  of  the  engagements.  Consequently,  a  central  computer 
failure  or  malfunction  is  catastrophic  -  the  entire  exercise  must  be 
halted  or  be  reinitiated  after  the  failure  is  corrected.  In  order  that 
all  of  the  required  data  be  available  at  the  central  computer  location, 
it  is  necessary  that  a  telemetry  link  be  operational  at  all  times. 
Failure  of  the  telemetry  link  is  as  catastrophic  as  a  computer  failure. 

In  support  of  the  large  central  computer  is  an  equally  large 
and  complex  software  package,  which  is  costly  and  difficult  to  maintain. 
The  human  resources  required  to  operate  and  maintain  the  computer,  the 
software,  the  telemetry  system,  and  the  other  instrumentation  elements 
of  the  system  are  also  quite  large  -  and  in  some  cases  larger  than  the 
forces  involved  in  the  test. 

A  final  consequence  of  the  present  instrumentation  is  that  all 
tests  must  be  performed  wherever  the  equipment  happens  to  be  in  place. 
The  existing  instrumentation  is  transportable,  but  by  no  means  mobile; 
therefore,  tests  are  infrequent  and  typically  very  expensive. 

1-1.2  Results  of  the  FY  1978  Instrumentation  Study  Effort. 

With  today's  microprocessors  and  large-scale  integration  tech¬ 
nologies  it  is  now  possible  to  develop  a  highly  modular  set  of  force-on 
force  instrumentation.  This  instrumentation  is  based  on  the  premise 
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that  each  player  carries  his  own  computer  with  functional  subsystems 
supplied  on  an  as-needed  basis.  The  system  architecture  takes  the  form 
of  "plug-in"  modules  which  interface  to  the  computer  through  a  standard 
peripheral  bus.  This  modular  concept,  coupled  with  the  standard  inter¬ 
face,  allows  future  improvements  (e.g.,  addition  of  GPS/NAVSTAR  for 
position  location)  to  be  incorporated  with  no  adverse  impact  on  the 
other  system  elements. 

The  central  computer  system  can  now  be  reduced  to  a  single 
easily  maintained  minicomputer;  or,  it  can  be  eliminated  entirely  since 
each  player  is  independent  and  can  perform  all  the  necessary  calculations 
for  tracking  his  position  and  scoring  weapons  engagements.  This  concept, 
in  and  of  itself,  eliminates  the  catastrophic  system  failure  modes  seen 
in  earlier  systems.  It  also  greatly  reduces  the  manpower  requirements 
for  operations  and  maintenance.  The  software  required  by  each  player  is 
relatively  straightforward  and  event-driven  (external  inputs). 

From  the  above,  it  can  be  seen  that  position  location,  data 
acquisition,  data  processing,  and  recording  can  now  be  done  on  compact 
instrumentation  located  on  individual  players.  The  existing  technologies 
have  reached  the  stage  of  development  where  it  is  possible  to  develop, 
with  low  risk,  a  simple,  decentralized  instrumentation  system  which  has 
the  following  features: 

1.  Modularity  —  The  addition  of  players  does  not  require  re¬ 
engineering  or  major  software  reconfigurations. 

2.  Mobility  —  It  will  be  practical  to  test  at  training  sites 
throughout  the  United  States  and  Europe. 

3.  Graceful  Degradation  —  The  system  fails  player-by-player. 

A.  Reduced  Support  —  It  requires  a  minimum  of  orchestration 

during  set-up  for  each  trial. 

5.  Directly  Convertible  to  Training  —  The  use  for  training  will 
be  a  subset  of  the  total  capability. 
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The  TNF  S  2  Instrumentation  Development  program  is  a  multi¬ 


contractor  effort  with  the  BDM  Corporation  acting  as  the  system  int- 
grator.  The  scope  of  the  FY  1979  instrumentation  development  effort  was 
to  begin  the  development  of  the  individual  player  elements  and  to  demon¬ 
strate  their  capability  in  engineering  brassboard  configuration.  Specific 
tasks  which  have  been  accomplished  are: 

1.  Updating  and  revising  of  the  Instrumentation  Development  Plan. 

2.  Hardware  and  software  development  of  the  overall  player  pack 
architecture,  executive  control  system,  data  logging,  and  the 
audio/cueing  elements. 

3.  Development  of  subsystem  specifications  and  acceptance  proce¬ 
dures  for  the  weapons  effects,  RF,  and  LORAN  sybsystems. 

4.  Technical  monitoring  of  the  DNA-selected  vendors  who  are 
supplying  instrumentation  subsystems. 

5.  Integration  of  the  prototype  instrumentation. 

6.  Demonstrate  in  the  BDM/TAC  R&D  Laboratory  or  at  the  DNA- 
selected  vendors  facilities  the  capability  of  the  prototype 
instrumentation  to  meet  the  design  specifications. 
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1-1.4  TNF  S  Instrumentation  -  System  Design  Philosophy. 

2 

The  TNF  S  Instrumentation  is  being  developed  utilizing  a 
highly  modular  design  approach.  The  instrumentation  will  distribute  the 
processing  capability  to  the  individual  player,  thereby  reducing  the 
telemetry  bandwidth  and  the  need  for  a  large  processor  at  the  central 
facility. 

The  individual  player's  computer  is  a  high  performance,  versa¬ 
tile,  general-purpose  process  controller  (a  process  may  be  software  [a 
calculation]  or  hardware  [a  response  signal]).  Processes  are  initiated 
by  stimuli  from  the  player's  external  environment.  Two  examples  of  such 
stimuli  are  position  location  signals  and  weapon  simulator  laser  signals. 
The  processes  which  can  be  initiated  are  determined  by  the  computer's 
ability  to  sense  these  external  stimuli.  Depending  upon  a  player's  role 
in  a  given  scenario,  he  may  or  may  not  require  access  to  all  available 
external  signals.  Consequently,  the  hardware  which  provides  access  to 
these  stimuli  (e.g.,  radio  receivers,  laser  sensors,  etc.)  is  provided 
in  the  form  of  "plug  in"  modules  which  interface  to  the  computer  via  a 
standard  peripheral  bus.  Modules  are  provided  to  a  player  on  an  as- 
needed  basis,  dependent  upon  his  function  in  a  particular  scenario. 

The  modular  concept  coupled  with  the  standard  interface  allows 
future  improvements  in  technology  to  be  incorporated  with  no  adverse 
impact  on  the  remainder  of  the  system. 

Since  the  player-carried  computer  performs  all  the  calculations 
for  tracking  position  and  scoring  engagements,  the  massive  central 
computer  is  reduced  to  either  a  single  minicomputer  or  none  at  all. 
Elimination  of  the  large  central  computer  also  eliminates  catastrophic 
failure  modes  -  the  system  degrades  gracefully,  player-by-player,  if  at 
all.  Furthermore,  small  size  makes  the  system  inherently  mobile.  Since 
a  great  many  of  the  support  personnel  requirements  of  a  conventional 
system  derive  from  operation  of  the  central  computer,  those  too  are 
eliminated.  Finally,  the  software  required  by  each  player  computer  is 
fundamentally  simple  -  it  need  only  perform  computations  involving  a 
single  player. 
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Thus,  the  concepts  of  modularity  and  distributed  intelligence 
allow  for  design  of  a  system  which  is  highly  flexible  and  mobile,  adapts 
easily  to  changes  in  requirements  or  technology,  and  eliminates  the 
serious  shortcomings  of  existing  equipment. 

The  use  of  modular  instrumentation  is  somewhat  different  from 
standard  approaches  to  testing.  One  must  examine  the  issue  at  hand  to 
determine  the  scenario  involved  (i.e.,  force-on-force,  procedural,  time- 
motion,  etc.).  One  must  then  determine  what  data  are  required  for 
analysis  (i.e.,  position,  real-time  casualty  assessment,  etc.),  and  in 
some  cases  the  necessary  accuracy  or  precision.  Finally,  any  unique 
requirements  must  be  determined  (i.e. ,  weather  monitoring,  toxic  gas 
monitors,  etc.).  This  process  provides  the  overall  functional  require¬ 
ments  of  the  instrumentation  system  as  a  whole.  Using  the  modules 
available,  one  then  very  quickly  assembles  a  system  that  meets  those 
requirements. 

The  modularity  of  the  instrumentation  manifests  itself  at  two 
levels.  First,  one  builds  a  system  from  the  three  modular  subsystems 
depicted  in  Figure  1.  These  are  the  master  station,  the  player  packs, 
and  the  communications  system.  At  the  second  level,  each  of  the  sub¬ 
systems  selected  is  further  customized  by  the  addition  of  the  appropriate 
functional  hardware  modules. 

1-1.4. 1  Player  Pack. 

A  player  is  any  individual  or  object  which  is  instrumented 
2 

with  a  TNF  S  player  pack.  Examples  are:  humans,  vehicles,  doors, 
weather  stations,  gas  sensors,  television  cameras,  bombs,  etc. 

Since  each  player  carries  his  own  computer,  he  functions 
autonomously.  A  player's  "signature"  or  functional  identity  is  deter¬ 
mined  by  the  module  set  he  carries.  Thus,  while  a  human  very  likely 
carries  a  weapon  simulator  module,  a  door  or  weather  station  most 
probably  does  not. 
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Figure  1.  LORAN-C  decentralized  system. 


The  primary  element  of  any  player  is  of  course  the  player 
pack,  shown  in  Figure  2.  Without  a  player  pack,  the  individual  in 
question  does  not  exist  as  far  as  test  control  elements  are  concerned. 

His  position  cannot  be  tracked  and  he  cannot  engage  or  be  engaged  by 
other  players. 

The  player  pack  itself  consists  of  a  fixed  part  called  the 
Executive  Control  System  (ECS),  and  a  variable  part  consisting  of  the 
particular  mix  of  functional  modules  (i.e.,  the  player's  unique  identity). 
Every  player  pack  contains  the  ECS,  consisting  of  the  microcomputer,  the 
battery  pack,  the  chassis,  and  the  peripheral  bus.  Figure  3  illustrates 
the  ruggedized  packaging  of  the  player  pack. 

The  ECS  microcomputer  consists  of  a  microprocessor,  an  interrupt 
controller,  the  requisite  clock  generation  circuitry,  memory  and  memory 
decoders,  and  peripheral  bus  drivers. 

The  peripheral  bus  carries  the  necessary  control  signals  to 
all  of  the  functional  modules.  All  the  peripheral  bus  connectors  are 
identical;  consequently,  any  module  can  be  plugged  in  at  any  point  on 
the  bus.  Use  of  a  standard  common  interface  greatly  reduces  the  cost 
and  development  time  of  new  hardware  and  the  associated  software. 

Software  for  ECS  is  generically  separable  into  two  classes  - 
control  codes  and  computational  codes.  The  control  codes  have  all  the 
features  of  a  prioritized,  interrupt-driven,  multi-tasking  operating 
system.  The  computational  codes  perform  such  tasks  as  RTCA,  PL,  etc. 

1-1. 4. 2  Master  Station. 

The  master  station  has  been  designed  to  serve  a  wide  variety 
of  functions.  It  is  a  multi-user  configuration  and  can  perform 
several  tasks  simultaneously.  Even  though  it  has  this  capability,  it  is 
quite  small,  with  the  computer  itself  occupying  only  two  equipment 
racks.  The  Master  Station,  Charging  Station,  and  the  Weapons/Ammunition 
Stations  are  shown  in  the  projected  site  configuration  in  Figure  4. 


Fire  Position 

■«nfrAc-j*«ii-Tn 

Figure  4.  Master  station  deployment. 
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The  operations  and  maintenance  function  is  available  concur¬ 
rently  with  all  other  functions.  It  consists  primarily  of  calibration 
and  functional  testing  of  the  player  packs  and  the  communications  link 
(if  used).  In  this  role  it  is  anticipated  that  sufficient  software  is 
made  available  so  that  the  technician  performing  those  duties  need  only 
type  a  command  to  "test"  and  wait  for  an  indicator  to  signify  "good/bad." 
This  allows  maintenance  to  be  done  by  a  less  highly  skilled  individual 
than  might  otherwise  be  the  case. 

During  pretest,  the  master  station  will  supply  the  player 
packs  with  test  and  test-site  specific  constants,  such  as  the  coordinates 
of  transponders,  and  provide  for  a  field  calibration  operation.  An 
example  of  a  field  calibration  operation  might  be  for  the  player  to 
stand  on  a  pressure  switch  and  fire  his  laser  weapon  simulator  at  a 
specific  target.  He  would  in  turn  be  fired  upon  by  an  emplaced  laser. 

Both  the  player  and  the  target  must  score  a  hit  and  indicate  certain 
predetermined  scoring  data. 

With  the  communications  system  in  use,  the  master  station  can 
control  test  timing,  start  and  end  testing,  all  data  traffic,  transmit 
simulated  indirect  fire  data,  and,  if  required,  collected  stored  infor¬ 
mation  from  the  players  to  generate  a  real-time  display  of  player  activity. 

In  the  quick-look  analysis  mode,  the  master  station  debriefs 
the  player  packs  and  validates  the  data  structures.  It  further  compares 
the  player  data  against  the  test  measures  of  effectiveness  for  rapid  in¬ 
field  test  validation  (at  this  point  the  test  may  be  re-played  if  necessary 
without  total  re-deployment).  Finally,  it  produces  a  merged  test  time¬ 
line  tape  for  use  in  detailed  test  analysis. 

1-1.4. 3  Communications  System. 

The  RF  Communications  system  has  been  developed  to  provide 
two-way  communication  between  the  master  station  and  the  individual 
players.  In  the  communications  mode,  the  master  station  initiates  all 
requests  for  player  data  and  acts  as  a  central  test  controller.  This 


21 


CO 


tea 


tute 


can 


be 


de»c 


civa 


teb 


at 


tbe 


©as 


3cet 


sea 


ti°a 


vi  V 


tb 


no 


deg,* 


aba 


tioo 


Lttet I * 


ece 


ivet  ■ 


sVs 


tetc 


tua' 


.ctv 


ons  ■ 


ebeW 


,eats 


idb 


tbe 

anb 

coatt 

loi 

3ntcoi- 

tcaa 


cbe  ^v,p  mai°  ;  cowPutei:  rtob  at 

-  a„_  vooic  ^oUt  at  tbe 

to1’  rf.t  “llh  ,.r  «vten»« 


lu4e  «  tv  »“9tet  6tatt«.»- 
»tet£>cli  -  t»  c^te\  »t.tWi  ^ 


ind 


roasted 

>te^ 


scat 


dons  i 


y'E.Gk 

vjitb 


ItlC- 


rePea^ 

.nicom?atet  nttob  at  tbe  aCb  ^avet' 

-4;;;ulth  ^ »» e;^°^ « 

10g,ic  ranst>otld  t  anb  i-°S>  is  be^ag  tati°uS’ 

.eve*^1  • onS  sV*teW  .  te\>eatet  bat* 

0)  a  cecei^1  ^  ^uaic^1  ^  roaste*  ^  ^  pvjlse  ?°  sUbsV« 

bbe  -nits  a  -tavet s*  ,  ,„at)ons  ..^tcai 


mia 


iti^a 


D„  tv.  ^“’;he  -rf* 

a^J*  .<>  to  w  ^i6“l 


10 

lb  —de*  v 


anb 


VjX> 


cepe 


ate* 


Ltaa 


sPoa 


tew 


Figure  5.  Repeater/transponder. 


1-2  INSTRUMENTATION  DEVELOPMENT  SYSTEM. 

The  instrumentation  development  system  is  a  multipurpose, 

multiuser  engineering  tool  to  be  used  in  the  development  of  both  hard- 

2 

ware  and  software  for  all  three  of  the  TNF  S  instrumentation  subsystems 
It  is  configured  to  have  the  capability  of  serving  in  three  modes:  (1) 
multiuser  development  system  for  the  player  pack  electronics,  (2)  quick- 
look  and  master  station  development,  and  (3)  fieldable  master  station. 

This  system  is  critically  necessary  for  player  pack  development. 
High-performance  microcomputers  such  as  ECS  are  very  complex  sequential 
and  combinatorial  logic  networks.  Their  characteristics  and  critical 
paths  are  well-known  but  nontrivial.  The  development  system  provides 
the  means  to  emulate  the  behavior  of  the  entire  system  under  development. 
Without  such  a  development  tool,  the  microprocessor-controlled  equipment 
can  be  expected  to  contain  many  "hidden"  catastrophic  logic  paths  which 
become  evident  only  after  the  equipment  is  fielded.  Often  these  problems 
occur  only  under  conditions  which  never  arise  in  the  engineering  laboratory. 

Since  the  master  station  and  the  development  system  are  essen¬ 
tially  the  same  equipment,  many  of  the  procedures  and  special  test 
equipments  produced  during  the  player  pack  development  phase  can  be 
transferred  directly  to  the  field  operations  and  maintenance  facility. 

The  commonality  of  the  master  station  and  the  instrumentation 
development  system  also  allows  quick-look  analysis  software  development 
to  proceed  in  parallel  with  the  hardware  development  using  the  same 
development  system. 

Furthermore,  the  instrumentation  development  system  provides 
the  bulk  of  the  capability  required  for  the  depot  maintenance  facility 
addressed  in  Section  IV. 

Because  the  instrumentation  development  system  is  common  to  so 

2 

many  phases  of  the  overall  TNF  S  test  capability  development,  and 
because  it  is  critically  necessary  for  hardware  and  software  development, 
it  must  be  considered  an  early  acquisition  item. 
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TNF  S2  INSTRUMENTATION  SUMMARY. 

Each  of  the  subsystems  contains  a  fixed  core  of  electronics 
analogous  to  a  multi-process  controller;  the  modules  incorporated  then 
determine  what  the  various  control  processes  are  and  when  they  are  acti¬ 
vated.  In  order  to  maintain  flexibility,  provide  for  rapid  system¬ 
building,  and  allow  for  future  growth,  the  core  of  each  subsystem  must 
meet  the  following  objectives: 

1.  Capacity  —  It  must  have  the  capacity  to  handle  additional 
loading  generated  by  future  requirements. 

2.  Expandability  —  It  must  be  easily  expanded  to  incorporate  new 
functional  modules. 

3.  Flexibility  —  It  must  easily  incorporate  improvements  to 
existing  modules. 

4.  Adaptability  —  It  must  adapt  easily  to  new  or  nonstandard 
uses  of  existing  modules. 

5.  Independence  —  It  must  operate  properly,  independent  of  the 
particular  mix  of  modules  implemented. 

Likewise,  the  modules  available  to  each  subsystem  must  meet  an 
additional  set  of  objectives: 

1.  Common  Interface  —  All  must  utilize  a  standard  common  inter¬ 
face  to  simplify  both  the  bus  structure  and  the  software 
protocols . 

2.  Independence  —  Proper  operation  of  a  module  must  not  depend 
on  the  presence  of  another  module  (unless  its  purpose  is  to 
enhance  the  capabilities  of  that  module).  Use  of  a  module 

should  not  preclude  the  use  of  other  modules. 

2 

The  TNF  S  instrumentation  elements  and  their  developer  are 
shown  in  Figure  6.  An  important  feature  to  be  noted  is  the  use  of  common 
elements  in  all  of  the  major  systems.  The  master  schedule  for  the  develop¬ 
ment  of  the  15  prototype  and  50  production  units  is  shown  in  Figure  7. 
Details  of  the  development  schedule  will  be  addressed  in  Section  IV  of 
this  report. 
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SECTION  II 

FUNCTIONAL  ELEMENT  DEVELOPMENT  STATUS 


2-1  INTRODUCTION. 

2-1.1  Scope  of  the  FY  1979  Development  Effort. 

The  scope  of  the  effort  being  reported  was  to  develop  and 

2 

verify  preliminary  designs  for  the  elements  of  the  TNF  S  instrumentation 
system.  Because  of  the  key  role  of  the  player  pack,  the  greatest  effort 
was  concentrated  on  its  development.  To  better  utilize  available  exper¬ 
tise  and  reduce  the  total  costs  to  the  government,  this  has  become  a 
multi-contractor  effort  coordinated  for  DNA  by  BDM.  Whenever  subsystems 
or  subassemblies  can  be  provided  by  contractors  whose  primary  business 
is  supplying  such  assemblies  those  contractors  have  been  utilized  with 
BDM  providing  specifications  and  performing  the  system  integration. 
Throughout  the  entire  program,  a  low  risk  approach  has  been  followed. 
Whenever  possible,  existing  subsystems  have  been  used.  If  no  suitable 
subsystem  exists,  one  has  been  designed,  either  by  BDM  or  another  con¬ 
tractor,  using  existing  components  and  well-proven  design  rules. 

The  low  risk  approach  has  been  highly  advantageous  in  terms  of 
both  cost  and  schedule.  The  Phase  I  player  pack  brassboard  stage  is 
nearly  complete.  Design  of  the  RF  repeaters  is  nearly  complete  and  the 
Master  Station  design  is  well  underway. 

VEGA  Precision  Laboratories  is  under  contract  to  DNA  and  will 

provide  RF  transceivers.  International  Laser  Systems  is  devel¬ 
oping  new  solutions  to  old  problems  in  the  area  of  weapon  simulators. 

BDM  has  worked  closely  with  both  contractors  to  assure  that  the  opera¬ 
tional  goals  are  both  realistic  and  achievable  using  the  low  risk  design 
rule. 

2-1.2  Player  Pack  Development. 

As  stated  earlier,  the  player  pack  is  the  key  element  of  the 

2 

TNF  S  instrumentation  system.  Consequently,  the  bulk  of  the  total 
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design  effort  has  been  dedicated  to  the  player  pack.  A  phased  approach 
—  brassboard,  prototype,  production  —  has  been  adopted  to  ensure  that 
the  operational  characteristics  of  the  final  production  model  are  as 
close  to  desirable  as  possible.  In  some  cases  (notably  the  microcom¬ 
puter)  operational  shortcomings  were  recognized  early  and  a  Phase  II 
design  is  already  in  progress. 

Many  of  the  criteria  for  the  player  pack  are  nearly  mutually 
exclusive:  High  speed  real-time  operation  and  low  power  consumption; 
Modularly  flexible  and  small  size;  operation  over  several  hours  and  low 
weight  (batteries).  To  achieve  these  contradictory  goals  some  highly 
innovative  techniques  have  been  used.  Power  is  cycled  to  low  duty  cycle 
components  to  reduce  total  power  consumption.  CMOS  logic  is  used  where- 
ever  high  speed  is  not  critical.  Finally,  a  great  deal  of  effort  has 
been  expended  in  properly  partitioning  the  player  pack  circuitry  to 
reduce  the  size  of  connectors  and  still  provide  adequate  flexibility  for 
future  growth. 

Software  development  has  lagged  due  to  procurement  difficulties 
with  the  GFE  Instrumentation  Development  System.  Nonetheless,  it  is 
anticipated  that  three  brassboard  player  packs  will  begin  field  testing 
in  late  April  1980. 

The  following  paragraphs  provide  a  detailed  account  of  the 
current  status  of  each  of  the  component  elements  of  the  player  pack. 
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Executive  Control  System  Microcomputer 

The  requirement  to  incorporate  a  microcomputer  in  the  player 

2 

pack  stems  from  the  real-time  nature  of  the  TNF  S  scenario.  As  fire 
activity  reaches  a  maximum  during  such  tests,  the  ability  of  the  instru¬ 
mentation  system  to  respond  to  events  is  taxed.  It  is  for  this  reason 
that  large  central  site  computing  facilities  have  proven  ineffective  in 
handling  real-time  data  at  a  rate  to  ensure  optimum  realism.  The  micro¬ 
computer  on  the  other  hand  provides  immediate  response  on  the  player  to 
events  as  they  occur.  Its  job  is  to  coordinate  the  activity  of  the 
instrumentation  within  the  player  pack  in  order  to  log  real-time  data, 
compute  the  player's  status  (hit/wound/kill) ,  and  provide  an  intelligent 
means  of  communicating  back  to  the  central  site  via  the  RF  network. 

Historically,  implementations  of  microcomputers  have  suffered 
from  a  lack  of  support  from  their  vendors.  This  has  been  quite  evident 
in  the  last  five  years  and  is  largely  due  to  the  growing  family  of 
microprocessors.  As  microprocessors  have  become  the  heart  of  many  new 
instrumentation  designs,  manufacturers  have  continually  up-graded  their 
parts  and  designed  new  and  in  some  cases  better  parts.  This  put  the 
average  lifetime  of  a  design  at  about  two  years  and  did  not  enable  the 
manufacturers  to  develop  full  support,  both  software  and  hardware,  for 

their  products.  To  circumvent  this  pitfall,  a  microprocessor  from  Texas 

2 

Instruments  has  been  selected  for  the  TNF  S  application.  For  a  couple 
of  years  this  device  has  been  the  only  16-bit  microprocessor  to  have 

2 

minicomputer  support  from  the  factory.  What  this  really  means  to  TNF  S 
is  that  field  service  and  direct  software  compatability  with  the  mini 
will  ensure  that  the  microcomputer  used  in  the  player  pack  is  not  going 
to  be  outdated  for  quite  some  time. 

2-2.1  Central  Processing  Unit 

There  are  several  components  involved  in  the  design  of  a 
microcomputer.  Each  of  the  major  components  contributes  unique  capa¬ 
bilities  to  the  system  and  the  design  effort  of  the  microcomputer  has 
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been  made  to  optimize  this  board  for  the  TNF  S  application  at  the  same 
time  providing  for  some  expansion.  As  a  result,  modularity  and  flexi¬ 
bility  have  been  key  design  considerations. 

Figure  8  is  the  block  diagram  of  the  first  brassboard  micro¬ 
computer  which  was  designed  and  built  this  year.  The  major  components 
have  been  depicted  as  blocks  and  provide  the  following  capabilities  on 
the  microcomputer  board: 

(a)  DIRECTLY  ADDRESSES  UP  TO  64K  BYTES  OF  MEMORY 

(b)  15  PRIORITIZED  INTERRUPTS 

(c)  BOOTSTRAP  READ  ONLY  MEMORY  (IK  BYTE) 

(d)  REAL  TIME  CLOCK 

(e)  SERIAL  COMMUNICATIONS  REGISTER  UNIT 

(f)  HARDWARE  ARITHMETIC  PROCESSING 

As  mentioned  before,  the  Phase  I  (brassboard)  microcomputer 
concept  was  designed  and  checked  this  year.  The  following  design  rules 
were  incorporated  for  all  the  player  pack  cards:  (1)  keep  the  design 
simple  —  eliminate  parts  and  complex  schemes  wherever  possible,  (2) 
keep  power  consumption  at  a  minimum  —  use  CMOS  parts  and  low  power 
devices  throughout,  (3)  make  the  design  with  testability  in  mind,  (4) 
consolidate  circuitry  as  much  as  possible  to  improve  reliability  and 
decrease  stocking  requirements,  and  (5)  use  worst  case  vendor  specifi¬ 
cations  on  parts  to  minimize  design  risk. 

2-2.2  Programmable  Systems  Interface 

While  the  Phase  I  microcomputer  card  was  being  tested,  an 
upgraded  design  concept  was  adopted  for  the  board.  As  with  most  engin¬ 
eering  projects,  a  "lessons  learned"  stage  provided  insight  for  a  Phase 
II  brassboard  which  will  prove  to  be  more  flexible  than  the  original 
microcomputer.  Also,  in  an  effort  to  reduce  the  overall  size  and  weight 
of  the  player  pack,  16K  bytes  of  Random  Access  Memory  will  be  incorpor¬ 
ated  onto  the  microcomputer  card  (see  Figure  9).  Additionally,  it  was 
decided  that  the  500mA  current  regulator  for  the  microprocessor  would 
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reside  on  this  board  since  no  other  components  require  this  supply. 

These  additions  to  the  microcomputer  board  will  result  in  the  use  of  a 
"multi-wire"  printed  circuit  board  fabrication  technique  which  is 
designed  to  condense  the  physical  size  of  electronic  subassemblies. 

The  Phase  II  microcomputer  is  in  the  design  stage  presently. 
Once  reviewed,  a  wire-wrap  version  will  be  assembled  and  debugged. 

After  it  has  been  functionally  checked  out,  temperature  tests  will 
begin.  This  will  involve  operating  the  microcomputer  and  exercising  on¬ 
board  circuitry  from  0  to  70°  Centigrade.  When  this  has  been  completed, 
the  prototype  multi-wire  boards  will  be  purchased.  All  other  system 
components  (Data  Logger,  Input/Output,  and  Communications  Interface  Unit 
beards)  will  then  begin  being  tested  for  functionality  and  compatabilitv 
with  the  microcomputer  board. 
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Memory  Subsystem 

For  convenience  of  discussion,  the  memory  subsystem  will  be 
divided  into  two  parts:  the  storage  memory  subsystem  and  main  memory 
subsystem.  The  storage  memory  subsystem  provides  for  the  permanent 
storage  of  all  software  that  is  used  by  the  player  pack  while  in  the 

normal  running  mode  of  operation.  When  the  system  is  turned  on,  the 

software  in  the  storage  memory  subsystem  is  copied  to  the  main  memory 
subsystem  and  then  executed.  The  storage  memory  subsystem  is  not 
accessed  again  unless  a  fault  is  detected  or  the  power  is  turned  off  and 
then  on  again. 

2-3.1  Storage  Memory  Subsystem 

The  storage  system  memory  provides  for  the  retention  of  the 
player  pack  software  when  there  is  no  power  applied.  This  board  holds 

the  basic  software  the  player  pack  will  use  during  a  test.  This  includes 

the  software  for  the  system,  tasks,  device  service  routines,  and  tables. 
The  basic  component  of  this  memory  is  EPROM  (Electrically  Programmable 
Read  Only  Memory).  This  device  can  be  electrically  programmed  to 
contain  any  software  and  it  remains  intact  with  interruption  of  power. 

The  software  can  only  be  erased  by  exposure  to  an  intense  ultra-violet 
light  of  a  specific  wavelength.  Accidental  erasure  is  virtually  impos¬ 
sible  while  inside  the  player  pack.  Once  erased,  these  devices  may  be 
reprogrammed. 

By  transferring  the  software  to  the  main  memory  subsystem, 

Random  Access  Memory,  the  software  can  dynamically  change  during  the 
test.  This  relaxes  the  restraints  on  software  generation.  This  is 
important  because  software  generation  is  a  significant  part  of  development 
cost.  The  EPROMs  are  not  used  except  for  a  few  seconds  at  initial 
power-up.  To  conserve  power,  the  ECS  can  turn  off  the  power  to  the 
EPROMs.  This  reduces  both  the  required  amount  of  energy  needed  and 
battery  weight.  The  functional  block  diagram  of  the  storage  memory 
subsystem  is  shown  in  Figure  10. 
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Because  the  EPROMs  are  used  for  so  short  a  period  and  the 


transfer  rate  is  unimportant,  they  have  been  configured  in  such  a  manner 
as  to  reduce  addressing  space.  The  EPROMs  are  configured  as  four  sets 
of  two  EPROMs  each.  The  four  sets  are  multiplexed  using  the  Communica¬ 
tions  Register  Unit  (CRU)  bus  to  control  the  multiplexing.  The  prototype 
EPROM  board  is  shown  in  Figure  11.  The  operation  of  the  EPROMs  proceeds 
as  follows: 

(1)  The  EPROM  power  is  turned  on. 

(2)  One  set  of  EPROMs  is  selected,  via  the  CRU  bus,  to  respond. 

(3)  The  software  from  that  EPROM  set  is  copied  into  the  main 

memory  subsystem. 

(4)  The  next  set  of  EPROMs  is  selected  to  respond. 

(5)  The  software  is  copied  into  the  main  memory  subsystem  and  so 

on  until  all  of  the  EPROM  sets  have  been  copied. 

(6)  The  power  to  the  EPROMs  is  turned  off. 

Some  RAM  (Random  Access  Memory)  has  been  added  to  the  board. 
Each  RAM  may  be  written  to,  read  from,  and  rewritten  to  independently 
and  in  any  order.  The  RAM  is  present  to  allow  easy  field  modification, 
either  temporary  or  permanent.  RAM,  however,  is  volatile.  Consequently, 
when  power  is  interrupted  the  data  stored  within  it  is  lost.  To  prevent 
this,  a  small  battery  on  the  board  keeps  power  applied  to  the  RAM  when 
the  rest  of  the  playerpack  is  off.  The  RAM  is  fabricated  from  CMOS 
(Complimentary  Metal  Oxide  Semiconductor)  technology  because  of  its 
extremely  low  power  requirements.  External  gating  prevents  writing  to 
the  bulk  of  the  RAM  unless  special  conditions  are  met  to  prevent  acci¬ 
dental  loss  of  data.  The  area  that  can  be  written  to  is  used  to  hold 
player  status  and  ID  information.  This  RAM  is  accessed  like  the  EPROMs, 
but  the  EPROMs  must  be  turned  off  to  do  so. 

2-3.2  Main  Memory  Subsystem 

The  main  memory  subsystem  contains  the  volatile  Read/Write  RAM 

memory.  RAM  is  a  mandatory  part  of  present  day  microprocessor  systems. 

In  the  most  fundamental  processor  application  RAM  is  used  only 

2 

for  temporary  information  storage.  For  TNF  S  this  memory  is  used  for 
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all  active  software,  instructions,  and  data.  More  specifically,  the  RAM 
will  hold  the  operating  system,  tasks,  device  service  routine,  tables, 

and  temporary  buffers.  An  estimate  of  8k  words  (8192  x  16  bits)  is 

2 

required  for  TNF  S  .  A  4k  bit  (4096  x  1)  static  RAM  is  the  basic  memory 
device.  Sixteen  of  these  devices  are  used  in  parallel  to  produce  a 
word.  Two  sets  of  these  blocks  are  used  to  get  the  total  memory  required. 
A  5-1/2  x  6-3/4  inch  board  is  used  for  RAM  memory.  The  4k  bit  RAM  devices 
selected  have  several  technological  advantages  over  other  RAMs.  They 
have  very  low  power  consumption  with  adequate  speed  and  density.  The 
RAM  devices  also  have  a  high  output  drive  capability.  In  order  to 
insure  reliable  performance,  parity  is  included  in  the  design.  Parity 
allows  the  processor  to  detect  single  bit  errors  in  stored  data. 

Figure  12  is  a  functional  block  diagram  of  the  RAM  board. 

Each  bank  of  RAM  is  composed  of  17  RAM  devices,  16  for  data  and  one  for 
parity.  The  decode  and  control  circuit  uses  the  upper  address  lines  and 
memory  control  signals  to  determine  selects  to  the  RAMs  and  proper 
timing.  The  parity  circuit  generates  a  parity  bit  for  each  write  that 
is  stored  in  RAM.  The  circuit  checks  the  parity  stored  with  that  gen¬ 
erated  when  the  word  is  read;  if  a  mismatch  occurs,  the  parity  error 
becomes  active.  Figure  13  shows  the  prototype  RAM  PCB. 

Due  to  the  sensitivity  of  the  cassette  tape  drive  unit  to 
shock  and  vibration,  a  feasibility  study  was  initiated  to  investigate 
other  alternatives  to  mass  storage  devices,  primarily  magnetic  bubbles 
and  bulk  (hybrid)  CMOS  RAM,  that  were  not  available  for  evaluation 
during  the  design  phase  of  the  data  logger  subsystem  module. 

Now  that  magnetic  bubbles  are  available  for  evaluation,  the 
decision  was  made  to  procure  an  evaluation  kit.  A  more  dense  and  reliable 
storage  medium  such  as  magnetic  bubbles  could  potentially  replace  both 
the  cassette  tape  version  of  the  DLS  and  the  software  storage  EPROM 
board. 

2-3.3  Bubble  Memory  Devices 

Bubble  memories  are  approaching  the  stage  where  they  are 


convenient  to  use.  These  devices  have  several  characteristics  which 
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Figure  12.  RAM  board  functional  block  diagram. 


make  them  attractive  as  a  high  density  data  storage  medium.  First, 
there  are  no  moving  parts  so  reliability  will  be  high.  A  single  bubble 
device  has  sufficient  storage  capacity  for  TNF  S2  and  expansion  is 
relatively  easy.  The  package  is  suitable  for  mounting  on  a  single  PC 
board,  the  form  factor  for  the  player  pack.  The  device  is  nonvolatile 
but  is  easily  written  too.  When  not  in  use,  the  bubble  memory  itself 
dissipates  no  power.  A  bubble  memory  device  will  replace  the  present 
data  logging  subsystem  using  the  minicassette  at  half  the  volume,  and 
also  replace  the  EPROM  board  (Storage  Memory  Subsystem) .  For  the  proto¬ 
typing  stage  system,  the  data  logging  subsystem  and  the  EPROM  board  will 
be  used. 
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2-4 


Data  Logging  Subsystem 


The  purpose  of  the  Data  Logging  Subsystem  is  to  provide  a  non¬ 
volatile  data  storage  capability  on  the  player  pack.  Since  the  storage 
requirement  for  the  player  pack  exceeds  the  addressing  capability  of  the 
ECS  microcomputer,  the  data  logging  subsystem  will  be  implemented  as  a 
separate  mass  storage  system.  The  data  to  be  stored  can  be  classified 
as  routine  tracking  records  and  event  initiated  records. 

Routine  tracking  data  provides  a  position/status  vs.  time 
player  history.  These  records  are  written  at  regular  intervals  and 
allow  the  analyst  to  produce  a  chronological  map  of  player  position  and 
status  during  a  test.  Event  initiated  data  does  not  occur  at  regular 
intervals,  but  only  as  circumstances  dictate.  These  records  must 
contain  all  the  analytically  necessary  information  concerning  such 
events  as  weapon  firing,  being  fired  upon,  etc.  To  the  greatest  extent 
possible,  these  records  will  contain  the  information  in  immediately 
useable  form  to  facilitate  the  Quick- Look  process. 

After  a  test,  the  data  stored  in  the  data  logging  subsystem 
will  be  unloaded.  This  will  be  done  either  through  the  RF  link  or 
through  an  input /output  port.  In  the  player  pack  application  the  data 
logging  subsystem  could  also  be  used  to  store  volatile  software  and 
constants  during  the  time  it  is  necessary  to  turn  off  the  power  to  the 
player  pack.  The  data  logging  subsystem  can  be  divided  into  three 
functionally  distinct  blocks.  Each  block  will  be  described  below. 

Refer  to  Figure  14,  block  diagram  of  the  data  logging  subsystem. 

2-4.1  Data  Storage  Medium 

The  storage  medium,  for  the  brassboard  prototype  units,  is 
implemented  with  a  miniature  cassette  tape  recorder  using  endless  loop- 
type  tape  cassettes  with  a  capability  of  storing  up  to  64K  bytes  (8 
bits/1  byte)  of  data.  The  tape  recorder  will  store  and  retrieve  data 
presented  to  it  under  command  of  the  data  storage  controller.  See 
Figure  15  for  the  prototype  cassette  data  logger  unit. 
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Figure  14.  Block  diagram 


2-4.2  Data  Storage  Controller 

This  portion  of  the  data  logging  subsystem  interfaces  to  the 
ECS  peripheral  bus.  The  data  storage  controller  supplies  the  necessary 
control  signals,  performing  timing,  data  serialization,  and  deserial¬ 
ization  functions  to  store  and  retrieve  data  to  and  from  the  storage 
medium. 

Functionally,  ECS  will  supply  the  data  storage  controller  with 
data  to  be  stored  in  the  data  logging  subsystem  through  the  Communica¬ 
tions  Register  Unit.  ECS  will  address  the  data  storage  controller  and 
program  it  with  command  and  control  information  to  be  used  when  storing 
data  onto  tape.  ECS  will  also  turn  the  power  on  and  off  to  the  controller 
as  to  avoid  unnecessary  power  drain  when  not  in  use. 

This  process  is  reversed  under  the  control  of  ECS  for  unloading 
the  stored  data.  ECS  will  access  the  data  storage  controller  and  read 
its  outputs  to  sense  the  status  of  the  device.  Likewise,  the  retrieved 
information  will  be  read  by  ECS  through  the  peripheral  bus. 

2-4.3  Data  Storage  Buffer 

For  a  tape  storage  system  to  be  efficient,  it  must  utilize  a 
buffer  so  that  data  can  be  stored  on  tape  in  blocks.  If  data  is  recorded 
on  tape  byte-by-byte,  too  much  tape  will  be  wasted  due  to  start  and  stop 
distances.  Therefore,  part  of  ECS  memory  (lk  bytes)  is  used  as  buffer 
memory.  When  full,  under  software  control,  ECS  will  present  the  data 
logging  subsystem  with  data  from  the  memory  buffer.  This  process  is 
reversed  for  unloading  the  data  stored. 
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2-5  Un Ivors al  I/O  Subsystem 

The  purpose  of  tlie  Universal  I/O  modules  is  to  enhance  the 
flexibilitv  of  the  player  pack  by  providing  two-way  electrical  communi- 
cation  with  the  outside  world.  The  plaver  pack  could  contain  one  or 
more  Universal  I/O  modules,  each  module  containing  the  required  iiardware 
to  enable  ECS  to  communicate  with  external  devices. 

On  a  human  player,  the  Universal  I/O  module  will  be  used  to 
control  cueing  devices,  monitor  posture,  supply  the  interface  to  the 
Loran-C  position  location  subsystem,  and  in  the  future  could  be  used  to 
monitor  blood  pressure,  heart  tale,  and  other  physiological  variables  as 
needed . 

On  vehicles,  the  Universal  I/O  module  will  be  used  to  control 
flash/bang/smoke  cueing  devices.  The  module  will  also  be  able  to  monitor, 
sense,  and  control  other  variables  specific  to  vehicles,  such  as  deacti¬ 
vating  the  engine,  sense  speed,  and  rpm. 

As  a  controller  for  test-specific  equipment,  the  player 
pack  could  be  used  to  activate  TV  cameras,  sense  intrusion  detectors, 
and  monitor  weather  stations  using  the  Universal  I/O  module. 

The  player  pack  will  also  have  the  capability  to  load/modify/ 
unload  software  from  external  sources  through  the  Universal  I/O  module. 

The  Universal  I/O  module  is  a  software-controlled  input /output  port. 

The  module  will  interface  with  almost  anything  such  as  RS-232,  IEEE-488, 
other  logic  devices,  and  data  buses,  all  just  by  changing  the  software. 

For  the  brassboard  and  prototype  units,  all  the  Universal  I/O 
module  functions  will  be  described  in  the  following  paragraphs. 

The  Universal  I/O  module  provides  16  input  lines  and  16  output 
lines.  Each  input  and  output  line  may  be  addressed  by  ECS  as  an  inde¬ 
pendent  digital  signal  (value)  or  in  groups  of  up  to  16  lines.  A  block 
diagram  of  the  Universal  I/O  Module  can  be  seen  in  Figure  16,  and  the 
prototype  PCB  is  shown  in  Figure  17. 
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ECS  communicates  with  the  Universal  I/O  module  through  the 
Communications  Register  Unit  bus  and  the  address  bus. 

The  Universal  I/O  modules  can  be  plugged  in  to  any  of  the  six 
peripheral  bus  connectors,  since  all  the  peripheral  bus  connectors  are 
identical.  The  peripheral  bus  carries  all  the  necessary  control  signals 
to  the  Universal  I/O  modules.  Each  Universal  I/O  module  decodes  the 
peripheral  bus  and  responds  when  it  is  issued  a  module  select  signal. 

Each  module,  during  initialization,  generates  a  special  inter¬ 
rupt  which  tells  the  CPU  that  the  module  is  present  in  the  system  and 
what  interrupt  is  associated  with  the  module.  This  is  useful  since  each 
module  can  be  located  in  any  of  the  six  peripheral  bus  connectors.  The 
interrupt  logic  provides  latched  interrupt  request  signal  to  the  ECS 
board. 

Each  output  has  an  open  drain  type  driving  Vertical  Metal- 
Oxide  Semiconductor  Field  Effect  Transistor  (VMOS  FET) .  The  outputs 
will  interface  to  any  system  requiring  a  5-30V  swing  and  to  almost  any 
load  requiring  several  hundred  milliamps  of  current.  Furthermore,  the 
lack  of  failure  from  secondary  breakdown  means  that  the  outputs  can 
drive  inductive  loads  such  as  relays. 

All  digital  inputs  to  the  I/O  module  accept  Transistor-Transistor 
Logic  (TTL)  level  signals  and  are  protected  against  any  input  voltages 
above  +5  Volts  or  below  ground  potential  (zero  Volts).  Hie  inputs  could 
therefore  interface  with  standard  24  Volt  logic  level  systems.  Further, 
the  inputs  are  protected  from  input  transients  of  up  to  two  kilovolts 
for  one  second. 
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Battery  Pack 

This  task  entails  the  selection  and  evaluation  of  the  optimal 

2 

power  source  for  the  TNF  S  player  pack.  Associated  with  the  battery 
implementation  is  the  power  conditioning  of  the  cell  array  voltage  to 
provide  regulated  voltage  and  current  sources. 

One  of  the  prime  objectives  is  to  assure  that  the  player 
pack  power  source  is  the  smallest  and  lightest  available  using  high 
technology  cells.  In  conjunction  with  the  prime  objective,  a  high 
efficiency  regulation  design  is  required.  Also,  a  simple  design  and 
configuration  is  necessary  to  minimize  the  cost  of  battery  re-charge/ 
replacement. 

2-6.1  Design  Evaluation 

Prior  to  the  actual  design  of  the  player  pack  power  source,  a 
market  survey  of  available  battery  types  and  their  characteristics  was 
made.  To  accomplish  this,  power  consumption  estimates  were  obtained 
from  the  members  of  the  electronic  design  staff.  This  rendered  a 
voltage,  current,  and  power  requirement  for  each  circuit  board.  Several 
battery  manufacturers  were  then  contacted  to  acquire  the  most  current 
available  literature  on  cells.  Table  2  indicates  a  compilation  of  data 
on  secondary  (re-chargeable)  ceils. 

TABLE  2.  CYCLE  LIFE  AND  POWER  DENSITY  FOR  SECONDARY  CELLS 


NI-CAD 

CYCLE  LIFE  300  min. 

W-hrs/lb.  14  typ. 

3 

W-hrs/in  1.5  typ 


SILVER-CAD 
150  mill. 

28  typ. 
2.1  typ. 


NI-ZINC 
150  min. 
23  typ. 
1.4  typ 


SILVER-ZINC 
25  min. 

45  typ. 

2 . 8  typ . 
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The  silver-zinc  cell  was  chosen  as  the  candidate  from  the 

secondary  cells  because  of  its  high  energy  density.  Taking  a  look  at 

primary  cells  (non-rechargeable) ,  the  most  dense  are  the  lithium  cells. 

Although  they  would  have  to  be  thrown  away  after  each  test,  a  50%  savings 

in  battery  weight  could  be  expected  if  lithiums  were  used.  A  cost 

trade-off  between  the  lithium  cells  and  the  silver-zinc  cells  revealed 

that  17  cycles  was  the  break-even  point.  In  other  words,  if  the  silver- 

zinc  cells  could  be  recharged  and  used  for  more  than  17  tests,  they 
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would  be  the  more  cost-effective  battery  for  the  TNF  S  player  pack.  At 
this  point  in  the  battery  survey,  it  was  noted  that  a  particular  silver- 
zinc  cell  from  Yardney  Electric  (LR-6)  had  been  developed  for  military 
applications  and  packaging  advances  had  increased  the  density  of  this 
cell  to  about  60  w-hrs/lb.  A  configuration  suitable  for  the  manpack 
using  these  cells  would  yield  a  rechargability  of  more  than  17  cycles, 
and  provide  a  total  battery  weight  of  less  than  four  pounds. 

Several  configurations  using  the  LR-6  silver-zinc  cell  were 
studied.  The  first  iteration  of  the  study  resulted  in  a  three  stack 
battery  configuration.  The  three  voltages  are  1.5V,  6V,  and  15V.  This 
configuration  required  only  15  cells  of  the  LR-6  and  resulted  in  a  total 
weight  of  about  2-1/2  pounds  (.93  Kg). 

2-6.2  Test  and  Evaluation  Program 

The  test  and  evaluation  program  involved  establishment  of  a 
cell  testing  protocol,  procurement  of  cell  samples,  and  design  of  an 
automated  cell  tester. 

The  test  protocol  characterizes  cell  operation  over  ranges  of 
temperature,  physical  orientation,  and  discharge.  Measurements  to  date 
have  defined,  or  are  confirming,  cell  performance  under  ten  environmental 
extremes  which  define  the  test  envelope.  Since  at  this  time  the  most 
satisfactory  cell  chemistry  available  for  player  pack  use  appears  to  be 
silver-zinc  cells,  their  performance  in  unfavorable  physical  attitudes 
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is  being  verified  by  test.  Discharge  temperatures  used  for  evaluation 
are  +35°F,  +70°F,  and  +150°F.  Discharge  orientations  include  upright, 
on-side,  and  inverted  positions.  Discharge  current  used  has  been  .7  Amp 
per  cell  and  will  be  revised  upward  to  .95  Amp.  To  reflect  new  worst- 
case  discharge  estimates,  a  single  conservative  charge  condition  of  .4 
Amp,  upright  at  +70°F  is  also  under  evaluation. 

For  the  present  study  15  each  of  the  LR-6  silver-zinc  type 
cells  manufactured  by  Yardney  Electric  Corp  were  procured.  These  are 
noted  for  their  high  density,  high  energy  storage,  deep-cycle  life, 
immunity  to  hostile  environment,  and  resistance  to  leakage.  Test  data 
to  date  is  incomplete  but  is  favorable  and  does  indicate  at  least  a 
nominal  viability  of  this  cell  type. 

2-6.3  Battery  Tester  Functional  Description 

To  acquire  the  large  amount  of  necessary  cell  test  data,  a 
cell  tester  was  designed.  Consideration  was  made  of  labor  savings,  the 
need  for  a  complete  and  permanent  test  record,  test  uniformity,  and 
lowest  risk  of  cell  damage  during  testing.  The  apparatus  described  here 
is  presently  in  use  and  meets  these  design  goals.  Refer  to  Figure  18, 
Battery  Cell  Tester  Function. 

During  tests,  each  cell  is  connected  to  either  a  charging  (CH) 
current  source,  or  a  discharge  (DIS)  dummy  load.  The  Electromotive 
Force  (EMF)  of  all  six  cells,  both  charge  and  discharge  currents  of  any 
one  selected  cell  were  permanently  recorded  on  an  8-channel  strip  chart. 

Inputs  governing  the  tester's  operation  are:  selection  of  the 
cycle  desired  (CH/DIS  SELECT),  the  present  upper  and  lower  test  levels 
(EMF  limits),  manual  and  automatic  cycling  commands  (Normal  Start/Stop), 
and  a  test  abort  signal  generated  by  any  comparator  failure  in  the  EMF 
sampling  logic  (malfunction  stop).  These  input  signals  control  the 
charge  and  discharge  relays.  A  charge  cycle  continues  until  all  cells 
under  test  have  charged  up  to  the  upper  assigned  EMF  limit.  A  discharge 
cycle  continues  until  any  single  cell  has  discharged  to  the  lower 
assigned  EMF  limit.  During  normal  tests  only  one  of  the  two  relays  is 
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Figure  18.  Battery  cell  tester  function. 
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energized.  A  malfunction  inhibits  both  relays,  isolating  all  test  cells 
from  the  tester.  The  strip  chart  recorder  increments  at  5-minute  inter¬ 
vals  and  records  both  during  charge  and  discharge  test  cycles. 

2-6.4  Voltage  and  Current  Regulators  Functional  Description 

A  set  of  voltage  and  current  regulators  were  designed  and 
prototyped  for  use  with  the  three  stack  configuration.  These  yielded  an 
average  power  conversion  efficiency  of  almost  80  percent,  providing  +12V 
DC  regulated,  +5V  DC  regulated,  and  a  500mA  regulated  current  source  to 
the  boards  under  test. 

As  the  circuit  design  for  the  player  pack  boards  evolved,  so 
did  the  power  consumption  estimate.  It  appeared  that  several  unforeseen 
circuit  alterations  could  greatly  influence  the  load  requirement  on  each 
of  the  three  battery  stacks.  At  this  point  it  was  decided  that  a  better 
approach  to  the  power  source  would  be  to  incorporate  a  single  stack  of 
cells  with  an  EMF  of  15V  DC.  All  of  the  regulated  voltages  and  currents 
will  be  derived  from  this  stack  using  high  efficiency  switching  type 
regulator  circuits.  Using  a  single  stack  has  several  advantages: 

(1)  The  complexity  of  the  battery  charging  station  can  be  decreased, 

(2)  The  maintenance  of  detecting  bad  cells  in  the  stack  and  fuse 
replacement  is  lowered,  and 

(3)  The  battery  monitoring  circuitry  becomes  much  simpler. 

Two  switching  regulators  have  been  designed  and  are  presently 

under  test.  They  are:  (1)  a  75  to  80  percent  efficient  +5V  DC  regulator 

for  the  logic  circuits,  and  (2)  a  55  percent  efficient  500mA  switching 

2 

current  source  (this  is  required  for  the  I  L  microprocessor).  There 
will  not  be  a  +12V  DC  regulator  for  use  by  the  circuit  boards,  but 
rather  the  unregulated  battery  voltage  will  be  distributed  to  each  slot 
requiring  on-board  regulation  if  needed. 

Figure  19  shows  the  functional  block  diagram  of  the  power 
supply.  The  batteries  are  short  circuit  protected  by  a  fuse  which  is 
mounted  in  the  battery  container.  A  connector  supplies  the  wiring  to 
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the  motherboard  circuits.  A  monitor  circuit  detects  the  critical  dis¬ 
charge  depth  for  the  batteries.  If  this  occurs,  a  signal  is  sent  to  the 
microcomputer  informing  it  of  this  condition.  A  fixed  time  later,  the 
monitor  turns  off  the  regulator  circuits  and  power  switch  to  prevent 
battery  discharge  beyond  the  critical  voltage. 

The  regulator  circuits,  along  with  the  microcomputer  system 
boards,  will  be  tested  and  verified  to  operate  up  to  170°F. 
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RF  SUBSYSTEM 


2 

The  RF  subsystem  in  the  TNF  S  instrumentation  application 
will  perform  three  distinct  functions:  bi-directional  communications 
between  the  various  players  and  the  master  station,  transponder  position 
location  which  provides  high  accuracy  positional  data,  and  direct 
ranging  to  allow  slant  range  measurement  between  an  attacking  player  and 
a  target  player.  Each  subsystem  will  be  discussed  in  detail  below.  To 
achieve  this  function,  each  player  will  use  an  RF  transponder  to  trans¬ 
mit  and  receive  RF  pulses  and  an  RF  Communications  Interface  Unit  (RF  CIU) 
to  encode  and  decode  messages  from  ECS. 

The  RF  subsystem  will  be  comprised  of  three  pieces  of  hardware: 
an  RF  transceiver  which  transmits  and  receives  RF  pulses,  a  message 
encoder/decoder ,  and  a  transponder  card.  The  RF  transceiver  is  being 
built  by  Vega  Precision  Laboratories,  Vienna,  Virginia.  The  message 
encoder/decoder  (RF  CIU)  is  being  built  by  International  Laser  Systems, 
Orlando,  Florida.  (This  is  an  identical  card  to  that  being  used  in  the 
weapons  effects  subsystem).  The  transponder  card  is  being  developed  by 
The  RDM  Corporation. 

2-7.1  RF  Communicat ion  Subsystem  Functions 

The  RF  communication  subsystem  will  prov'de  two-way  communica¬ 
tions  between  a  central  control  facility  and  various  system  player 
packs.  To  achieve  these  three  functions,  the  RF  transceiver  in  the 
player  pack  will  be  time  shared  between  the  player's  RF  CIU  and  the 
transponder  position  location  board  as  directed  by  the  master  station. 
System  flexibility  is  maintained  through  message  protocol  (handshaking) 
and  performance  is  optimized  through  the  internal  organization  of  the 
master  station  and  player  packs. 

To  maintain  system  flexibility,  the  master  station  will  con¬ 
trol  all  communications.  When  the  master  station  desires  information 
from  a  player  pack,  It  will  send  a  message  to  that  player  pack  requesting 
a  response.  The  master  station  can  send  a  message  to  an  individual 
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player  pack  or  to  all  player  packs.  When  the  master  station  is  requesting 
information  from  a  player  pack,  the  handshaking  will  be  as  follows: 
master  station  sends  a  message  to  a  player  pack  requesting  information, 
player  pack  responds  with  that  information,  master  station  sends  a  veri¬ 
fication  message  back  to  the  player  pack  indicating  the  receipt  of  valid 
data. 

The  heaviest  use  of  the  RF  communications  system  will  occur 
when  a  "real  time"  file  of  test  activities  is  being  maintained  at  the 
master  station.  In  this  mode,  most  of  the  RF  message  traffic  will  fall 
into  the  category  of  "player  tracking."  That  is  to  say,  the  master 
station  will  sequentially  poll  player  packs  for  their  position  (x,  y, 
and  z)  and  status  (wounded,  prone/standing,  etc.).  The  player  pack 
response  will  include  a  bit  which  will  tell  the  master  station  if  the 
player  pack  has  any  event  data  to  send  (events  will  be  such  things  as 
weapon  engagements,  etc.).  If  a  player  pack  response  indicates  event 
data  is  available,  the  master  station  requests  an  event  message.  Thus, 
if  a  player  pack  had  two  events  to  report,  the  handshaking  would  be  as 
follows:  (1)  request  tracking  messages,  (2)  send  tracking  data/have 

event  data,  (3)  request  event  message,  (A)  send  event  message/more  event 
data  available,  (5)  request  event  message,  (6)  send  event  message/no 
more  event  data  available,  (7)  send  verification.  Note  that  each  request 
for  further  data  verifies  receipt  of  the  previous  message. 

All  messages  from  the  master  station  will  consist  of  36  bits, 
and  all  player  responses  will  consist  of  72  bits. 

The  system  performance  will  be  optimized  by  minimizing  the 
turn  around  time  between  reception/interpretation  of  one  message  and 
transmission  of  the  next.  In  the  master  station  this  will  be  achieved 
by  using  fast,  high  power  hardware.  On  the  players  this  will  be  achieved 
by  having  them  anticipate  the  type  of  message  that  will  be  requested  by 
the  master  station,  calculate  CRC  (cycle  redundancy  check)  on  the 
message,  and  preload  it  into  a  buffer  which  can  be  transmitted  immediately 
upon  request  from  the  master  station. 
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2-7. 1.1  RF  Message  Duration 

Each  RF  message  will  consist  of  two  start  pulses  and  a  series 
of  information  pulses.  Each  information  pulse  will  contain  six  bits  of 
data.  Master  station  messages  will  consist  of  six  information  pulses, 
and  playerpack  responses  will  consist  of  12  information  pulses.  A 
typical  master  station  message  will  be  865ys.  This  number  is  predicated 
on  the  message  encoding  being  chosen  so  that  certain  bits  are  always 
zero. 

Player  pack  messages,  on  the  other  hand,  are  almost  completely 
unstructured  in  that  any  of  the  bits  can  be  high  or  low,  depending  on 
message  content.  The  time  analysis  assumes  that  all  bytes  are  sent  in 
the  player  pack  messages.  With  this  in  mind,  the  timing  for  a  player 
pack  message  will  be  as  follows:  two  start  pulses  —  80ys,  12  informa¬ 
tion  pulses  of  149ps  each,  total  transmission  time  is  1.868ms. 

With  the  handshaking  protocols  chosen,  there  will  be  two  types 
of  time  cycles.  The  first  time  cycle  will  be  the  RF  message  traffic 
associated  with  a  tracking  message,  and  the  second  cycle  will  be  the 
messages  associated  with  an  event.  Each  tracking  message  sequence  will 
require  4.6ms  and  each  event  message  sequence  will  require  an  additional 
3. 7ms. 

2-7. 1.2  System  Load  Due  to  RF  Message  Traffic 

To  calculate  the  total  load  on  the  system  due  to  RF  messages, 
let  us  assume  that  there  are  100  slow  players  and  10  fast  players  being 
tracked.  The  player  packs  on  the  slow  players  will  be  queried  once 
every  two  seconds,  and  the  player  packs  on  the  fast  players  will  be 
queried  five  times  a  second.  Thus,  over  a  two  second  interval  there 
will  be  150  tracking  cycle  interactions.  Further,  let  us  assume  that 
the  slow  players  have  a  total  of  100  events  which  occur  to  them  as  a 
group  in  any  two  second  interval.  Based  on  these  assumptions,  the  total 
system  load  can  be  calculated  as  shown  in  Table  3. 
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TABLE  3.  SYSTEM  LOAD  FROM  RF  MESSAGES 


MESSAGE  TYPE 

TIME  PER  MESSAGE 

NUMBER  OF  MESSAGES 

TOTAL  TIME 

Tracking 

4.60ms 

150 

•  69s 

Event 

3. 70ms 

110 

.407s 

Total  during 

a  2  second  interval 

1.097s 

(duty  cycle 

54.9%) 

2-7.2  Transponder  Position  Location  Subsystem 

The  transponder  position  location  system  will  be  the  high 

2 

accuracy  locating  system  of  the  TNF  S  instrumentation.  The  system  will 
work  by  having  players  measure  their  range  from  transponders  which  are 
located  around  and  within  the  playing  area.  By  knowing  their  range  from 
the  transponders  and  the  x,  y,  z  coordinates  of  each  transponder,  each 
player  can  perform  its  own  position  location  calculations. 

The  system  will  work  by  having  each  player  assigned  a  speci¬ 
fied  time  window  wherein  it  can  address  the  transponders.  Within  its 
window  the  player  will  sequentially  address  all  of  the  transponders  and 
make  the  range  measurements.  A  player  will  address  a  given  transponder 
by  transmitting  two  RF  pulses.  The  spacing  between  the  RF  pulses  will 
contain  the  address  information  for  the  transponder  being  addressed. 

When  a  transponder  hears  its  address  it  will  wait  for  a  fixed  amount  of 
time  and  rebroadcast  its  address  (two  pulses).  The  player  will  measure 
the  range  by  measuring  the  elapsed  time  from  when  it  transmits  the 
second  address  pulse  until  it  receives  the  second  returned  address 
pulse.  The  precision  of  the  range  measurement  will  be  one  meter. 

The  transponder  position  location  will  be  time  shared  with  the 
RF  communication  function.  This  will  be  done  by  having  the  master 
station  tell  all  the  players  and  repeater  stations  when  to  convert  into 
the  transponder  position  location  mode.  This  sequence  is  detailed  in 
Figure  20.  Note  in  this  figure  that  the  master  station  is  controlling 
all  RF  communication.  When  the  master  station  decides  it  is  time  for 
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the  system  to  do  a  position  location  update,  it  will  send  an  RF  message 
which  will  tell  a  group  of  players  to  get  ready  to  do  position  location. 
When  a  repeater / transponder  interprets  a  message  which  says  position 
location  is  about  to  start,  it  will  repeat  that  message  and  switch  to  a 
"look  for  start"  mode.  Similarly,  players  will  interpret  the  message, 
initialize  their  transponder  PL  boards,  and  go  into  a  look  for  start 
condition.  Once  the  master  station  has  determined  that  sufficient  time 
has  elapsed  for  the  player  and  transponder  hardware  to  be  initialized, 
it  will  send  out  two  RF  pulses.  These  two  pulses  will  have  the  effect 
of  starting  the  transponder  PL  cycle.  When  the  repeater  stations  hear 
these  two  pulses,  they  will  repeat  them  and  immediately  switch  to  the 
transponder  mode  of  operation.  Similarly,  when  players  hear  these  two 
pulses,  their  transponder  position  location  card  will  immediately  start 
operating.  Each  player  of  the  group  that  is  to  do  position  location 

will  have  a  time  window  assigned.  The  transponder  position  location 

card  will  automatically  measure  the  elapsed  time  until  the  players 
assigned  window  occurs.  During  its  window,  the  transponder  PL  board 
will  wait  for  a  guard  band  and  then  sequentially  address  each  one  of  the 
transponders  and  measure  the  range. 

1-7.1  D irect  Ranging 

Direct  ranging  will  be  similar  to  transponder  position  location 
in  that,  under  direction  of  the  master  station  a  direct  ranging  cycle 
will  be  performed.  During  this  type  of  cycle,  each  player  will  be  given 
a  window  in  which  it  can  perform  ranging  measurements.  In  its  window,  a 
player  will  be  able  to  measure  range  between  itself  and  two  other  players. 
This  function  will  be  achieved  by  having  the  player  act  as  a  transponder 
for  most  of  the  cycle  and  switch  to  an  interrogator  during  his  window. 

This  allows  other  players  to  perform  range  measurements  to  a  player  when 
it  isn't  performing  measurements  itself.  This  type  of  measurement  will 
be  useful  in  intervisibility  determination  and  attacking/target  player 
slant  range  determination.  In  a  50-player  test,  a  direct  ranging  cycle 
would  require  approximately  20ms. 


_/ 
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2-8 


Weapons  Effects  Subsystem 

In  order  to  provide  combat  realism  during  mock  live-fire 
engagements,  a  man-safe  simulator  for  direct  fire  weapons  is  required. 
Bore  sighted  lasers  have  been  used  in  the  past  to  provide  this  function. 
In  this  approach,  weapon  mounted  electronics  detect  a  muzzle  flash  and 
transmit  a  coded  laser  message.  Each  player  has  several  laser  detectors 
to  sense  an  illumination.  Such  systems  have  traditionally  suffered  from 
two  fundamental  operational  problems  (1)  during  close-in  engagements  it 
is  possible  (likely)  that  the  small  diameter  laser  beam  will  miss  all  of 
the  discrete  sensors  resulting  in  no  detectable  "hit"  at  nearly  point- 
blank  range  and  (2)  reflections  from  walls  and  floors  will  result  in 
"erroneous"  hits.  Both  of  these  detract  from  operational  realism. 

The  objective  of  this  task  is  to  provide  a  safe,  realistic 
weapon  simulator.  The  system  should  work  from  "point  blank"  range  to  at 
least  2 EM. 

'Hie  weapon  effects  subsystem  is  being  developed  by  Inter¬ 
national  Laser  Systems  of  Orlando,  Florida.  Part  of  the  subsystem  will 
also  be  used  to  encode  and  decode  messages  in  the  RF  communication 
subsyst  i'm. 

2-8.1  System  Operation 

The  players  will  fire  actual  weapons  using  blank  rounds. 
F.verytime  a  player  fires  a  blank  round,  the  weapon  effects  subsystem 
will  transmit  a  coded  message  using  an  eye-safe  laser,  mounted  to  and 
bore  sighted  with  the  barrel.  When  a  target  player  sensor  is  illuminated 
by  an  incoming  laser  message,  the  plaverpack  electronics  will  automati¬ 
cally  decode  the  message  and  pass  the  information  along  to  ECS.  ECS 
will  then  make  the  Real  Time  Casualty  Assessment  (RTCA)  decision  based 
on  the  content  of  the  laser  message  and  will  inform  the  player  when  he 
has  been  shot  at  and  near  missed,  wounded,  or  killed.  Thus,  realism  is 
gained  by  using  actual  weapons  with  blank  rounds  and  weapons  effects  are 
simulated  through  the  use  of  coded  laser  messages. 
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The  weapons  effects  subsystem  will  be  composed  of  three 
primary  elements.  The  first  element  will  be  weapon  mounted  electronics. 
This  will  consist  of  electronics  to  detect  the  firing  of  a  blank  round, 
to  communicate  that  information  back  to  the  rest  of  the  subsystem,  and 
to  fire  the  weapon-mounted  laser  on  command.  The  second  element  of  the 
system  will  be  the  harness-mounted  light  detectors.  This  will  consist 
of  both  discrete  and  area  sensors  that  are  mounted  on  a  player's  uniform. 
When  incoming  light  is  detected  by  any  one  of  the  sensors,  signal  lines 
will  communicate  this  information  back  to  the  Weapons  Effect  Communications 
Interface  Unit  (WECIU).  The  third  element  of  the  system  will  be  the 
WF.Cir  that  will  coordinate  the  activities  of  the  weapon-  and  harness- 
mounted  electronics,  encode  messages,  decode  messages,  and  communicate 
with  ECS. 

When  a  round  is  fired,  the  weapon-mounted  electronics  will 
detect  the  muzzle  flash  and  will  notify  the  WECIU  that  a  round  has  been 
fired.  When  this  occurs  the  WECIU  will  generate  an  interrupt  to  ECS  to 
inform  it  that  a  round  has  been  fired.  ECS  will  log  that  a  round  was 
fired  at  a  certain  time  and  will  give  a  transmit  command  to  the  WECIU. 

When  the  WECIU  gets  the  command  to  start  the  transmission,  it 
will  generate  and  transmit  the  proper  pulse  sequecce  for  the  message  to 
be  transmitted. 

At  the  target  player,  every  time  a  laser  pulse  is  detected  the 
light  detectors  will  immediately  send  a  digital  signal  to  the  WECIU. 

The  WECIU  will  decode  the  incoming  pulse  train  to  determine  if  it  is  a 
valid  message.  When  the  WECIU  has  decoded  an  entire  message  and  has 
determined  that  it  is  valid,  it  will  store  the  message  in  its  own  buffer 
memory  and  generate  an  interrupt  to  ECS  to  tell  it  that  a  message  has 
boon  received.  ECS  will  then  transfer  the  message  into  its  memory,  make 
the  appropriate  RTCA  decision,  and  log  all  of  the  information  in  its 
data  file. 

Two  additional  functions  performed  by  the  weapons  effects 
subsystem  will  be:  (1)  determine  which  part  of  the  body  was  illuminated. 
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and  (2)  determine  when  a  "wide  light  pulse"  occurs.  The  wide  light  pulse 
will  be  used  in  future  system  additions  to  detect  the  occurance  of  an 
explosion  from  an  area  weapon  such  as  a  hand  grenade. 

2-8.2  Unique  Characteristics 

2 

Several  unique  features  are  being  incorporated  on  the  TNF  S 
weapons  effects  subsystem.  One  of  these  is  the  use  of  area  light 
detectors.  These  will  be  arrays  of  fiber  optic  material  that  will  be 
sewn  onto  the  players  uniform.  All  of  the  fiber  ends  will  be  routed  to 
one  detector.  Thus,  whenever  a  laser  illuminates  any  part  of  the  area 
detector,  the  light  will  be  detected.  The  area  detectors  will  be 
useful  for  close-in  combat  where  the  laser  beams  will  be  fairly  small 
and  could  hit  any  part  of  the  body.  By  having  area  detectors,  a  hit 
anywhere  on  a  players  uniform  will  be  detected.  The  area  detector's 
long  range  sensitivity  is  not  as  great  as  discrete  detectors.  Therefore, 
at  least  one  body  area  will  have  both  an  area  detector  and  a  discrete 
detector.  The  area  detectors  will  be  primarily  useful  for  close-in 
engagements,  and  the  discrete  detectors  primarily  for  long  range  inter¬ 
actions  . 

One  unique  benefit  of  having  both  area  and  discrete  detectors 
will  be  that  it  provides  the  mechanism  to  discriminate  against  close-in 
shots  that  have  been  reflected  off  of  a  wall  or  floor.  With  present 
systems  it  is  possible  to  aim  at  a  wall  near  a  player  and  get  enough 
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reflected  light  to  trigger  his  sensors  and  score  a  hit.  In  the  TNF  S~ 
system,  tills  effect  can  be  discriminated  against  using  the  difference  in 
sensitivities  of  the  area  and  discrete  detectors.  If  two  players  are 
close  together  and  the  laser  has  been  reflected  off  of  a  wall,  the  light 
energy  will  be  scattered.  There  will  be  sufficient  energy  to  energize 
the  discrete  detector  but  not  the  area  detector.  Thus,  when  a  player  is 
illuminated  and  the  player  pack  determines  that  the  slant  range  from  the 
weapon  is  fairly  small,  the  area  sensors  can  be  polled.  I f  no  area 
sensors  registered  a  hit,  then  it  is  a  safe  assumption  that  the  laser 
beam  was  reflected  before  it  illuminated  the  player. 


Another  unique  aspect  of  the  weapons  effects  subsystem  is  that 
there  will  be  no  hard-wired  link  between  the  weapon-mounted  electronics 
and  the  WECIU.  Communication  between  these  two  elements  will  be  over  a 
bi-directional  proximity  link.  One  half  of  the  proximity  link  will  be 
mounted  on  the  stock  of  the  weapon  being  fired,  and  the  other  half  will 
be  attached  to  the  players  hand.  The  characteristics  of  the  link  will 
be  such  that  the  players  hands  must  be  within  a  couple  of  inches  of  the 
weapon  or  the  weapon  cannot  communicate  to  the  WECIU.  This  will  allow 
free  play  in  a  battle  so  that  a  player  can  fire  any  weapon.  This  bi¬ 
directional  link  generated  two  issues  which  had  to  be  addressed  in  the 
design.  First,  the  weapon  must  tell  the  WECIU  its  type  every  time  a 
round  is  fired,  and  there  must  be  positive  feedback  to  a  player  so  that 
he  knows  for  sure  that  his  laser  is  firing.  The  first  issue  is  resolved 
by  having  the  weapon-mounted  electronics  transmit  two  pulses  when  it 
detects  a  muzzle  flash.  The  separation  of  the  two  pulses  will  contain 
the  weapon  type.  The  second  issue  is  resolved  by  having  the  player's 
sonalert  give  a  beep  every  time  the  WECIU  board  transmits  a  message. 
Thus,  when  a  player  pulls  his  trigger,  he  will  hear  his  blank  round  fire 
and  that  will  be  immediately  followed  by  a  short  beep  from  his  sonalert. 

A  conceptual  diagram  of  how  the  weapons  effects  elements  will 
be  integrated  into  the  playerpaek  is  shown  in  Figure  21. 
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Figure  21.  Weapons  effects  subsystem  elements. 
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PACKAGING 


The  packaging  task  consists  of  providing  a  suitable  enclosure, 

appropriate  harnessing  or  mounting,  and  adequate  power  supplies  for  the 
2 

TNF  S  elements  under  consideration.  There  are  currently  three  identi¬ 
fied  elements  which  require  an  extensive  packaging  effort.  These  are: 

(1)  the  player  pack,  (2)  the  repeater  stations,  and  (3)  the  master 
station,  which  will  be  discussed  separately.  Each  of  these  elements 
have  different  environmental,  functional,  and  logistics  constraints  that 
impact  the  packaging  concepts. 

2-9.1  Player  Pack  Units 

The  player  pack  must  be  equipped  with  a  hardness  engineered 
for  comfort  over  long  periods  of  use.  The  electronics  package  must  be 
provided  with  a  light-weight,  weather-tight  enclosure.  This  enclosure 
must  allow  easy  access  to  the  electronics  for  maintenance  while  providing 
protection  against  water,  mud,  dirt,  etc.  Batteries  and  battery  compart¬ 
ments  must  be  provided  as  a  part  of  the  enclosure  (refer  to  Figure  22, 

2 

prototype  TNF  S  player  pack). 

A  market  survey  revealed  that  a  commercial  backpack  harness 
and  frame,  suitable  for  the  player  pack,  was  available.  The  harness  and 
frame  was  mounted  to  a  realistic  mockup  model  of  the  player  pack.  The 
harness  was  evaluated  and  decisions  were  made  to  also  evaluate  a  soft 
pack,  as  another  option.  A  soft  pack  would  consist  of  foam  cut  to  match 
the  contour  of  the  soldiers  back  and  the  player  pack  would  in  turn  be 
mounted  to  the  foam  enclosed  in  canvas. 

\ 

A  prototype  unit  of  the  card  cage  that  holds  the  circuit 
boards  internally  to  the  electronics  enclosure  was  fabricated  and 
evaluated.  It  was  found  that  if  certain  modifications  were  made,  the 
player  pack  could  be  reduced  in  both  size  and  weight.  The  modifications 
were:  (1)  to  move  the  RF  unit  out  of  the  main  card  cage  section  to  be 

mounted  on  the  outer  interface  panel  along  with  external  connectors 
(refer  to  Figure  23) ,  (2)  the  circuit  board  slots  were  re-arranged  so 
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Microcomputer 


Figure  22.  TNF-S  prototype  player  pack  for  footsoldi 


that  the  Data  Logging  Subsystem  utilizing  a  cassette  recorder  could  be 
replaced  with  bubble  memory  or  bulk  CMOS  RAM,  and  (1)  the  motherboard 
was  re-designed  so  that  the  Universal  I/O  module  could  be  placed  into 
any  slot  other  than  the  microcomputer  slot.  The  modified  card  cage  has 
been  fabricated  and  will  now  undergo  extensive  testing  and  evaluation. 

The  outer  prototype  electronics  enclosure  design  is  complete. 
The  enclosure  will  be  fabricated  shortly,  allowing  for  further  evalua¬ 
tion  and  testing  of  the  design. 

2-9.2  Repeater  Stations 

The  repeater  station  has  the  same  environmental  requirements 

as  the  player  pack.  However,  it  need  not  be  comfortably  harnessed. 
Additionally,  an  antenna  mast  (VEGA)  must  be  provided.  Batteries  for 
the  repeater  need  not  be  the  same  as  for  the  player  pack. 

An  initial  design  concept  has  been  formulated  for  the  repeater 
station  in  order  to  place  orders  on  long  lead-time  parts.  No  prototype 
units  have  been  fabricated  to  date.  The  batteries  will  initially  be  a 
low  maintenance  lead-acid  battery  to  supply  the  higher  power  required. 
2-9.3  Repeater /Transponder  Towers 

Tiie  towers  themselves  are  a  lightweight,  collapsable-type, 
constructed  with  aluminum  in  a  lattice  structure.  They  will  be  deployed 
by  a  two-man  team  for  installation  once  the  testing  area  has  been  sur¬ 
veyed  (refer  to  Figure  24,  Repeater  tower).  The  top  of  the  tower  will 
support  the  antenna,  transmitter  power  amplifier,  and  receive  preampli¬ 
fier.  The  remaining  electronics  will  be  housed  in  a  weatherproof  con¬ 
tainer  along  with  the  batteries  at  the  bottom  of  the  tower.  With  this 
configuration  it  is  reasonable  to  expect  a  maximum  payload  of  25  pounds 
for  the  tower.  For  a  50- foot  tower  weighing  approximately  25  pounds, 
system  integrity  will  be  maintained  in  winds  up  to  about  80  miles  per 
hour.  For  permanent  installations,  heavier  towers  will  be  used  and  wind 
velocities  of  over  140  miles  per  hour  are  easily  withstood. 
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MASTER  STATION  DESIGN 


The  preliminary  design  of  the  master  control  shows  it  to 
consist  of  three  trailers:  an  operations  and  maintenance  trailer  (O&M) , 
a  player  preparation  trailer,  and  a  weapons  and  ammunition  storage 
trailer.  The  design  calls  for  the  trailers  to  be  air  transportable  by 
either  two  C141s  or  a  C-5A.  The  eight  by  forty  foot  O&M  trailer  will  be 
provided  by  a  subcontractor.  The  acquisition  of  the  other  two  eight  by 
twenty  foot  trailers  is  anticipated  to  be  through  GFE  (FSN-8115-168- 
2275).  The  trailers  will  either  be  equipped  with  a  removable  under¬ 
carriage  or  will  be  transported  on  flat  bed  trailers. 

Figure  25  shows  a  possible  configuration  of  the  O&M  trailer. 
This  trailer  van  is  the  data  acquisition  system  and  control  center 
during  the  field  tests.  The  design  calls  for  the  trailer  to  be  divided 
into  three  areas  —  an  operations  area,  a  maintenance  area,  and  an  area 
for  the  environmental  control  equipment.  The  environmental  control 
equipment,  consisting  of  an  air  conditioner,  heater,  humidifier,  power 
conditioner,  and  power  distribution  system  would  be  housed  in  one  end  of 
the  trailer,  as  shown  in  Figure  25.  The  equipment  would  be  acoustically 
and  thermally  isolated  from  the  rest  of  the  trailer.  Access  to  this 
area  would  be  through  double  doors  at  the  end  of  the  trailer. 

The  remainder  of  the  trailer  would  be  the  operations  and 
maintenance  areas.  Field  level  maintenance  of  player  packs  and  associ¬ 
ated  hardware  would  be  conducted  in  the  area  indicated  in  Figure  25. 

The  area  would  contain  the  equipment  necessary  to  conduct  this  level  of 
maintenance  including  a  workbench,  equipment  rack,  and  several  storage 
cabinets.  A  nonrigid  divider  such  as  curtains  would  be  used  to  separate 
tiie  lighting  levels  between  the  maintenance  and  operations  areas.  The 
operations  area  would  contain  the  computers  and  all  hardware  necessary 
to  support  the  player  packs  and  transponders.  A  preliminary  list  of 
equipment  includes  three  video  display  terminals,  a  line  printer,  a 
digitizer,  two  equipment  racks,  and  two  computer  racks. 
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Figure  26  shows  the  player  preparation  trailer,  along  with  the 
weapons  and  munitions  trailer.  The  player  preparation  trailer  will 
contain  the  laser  detector  equipped  helmets  and  suits,  the  player 
packs,  spare  player  pack  batteries,  the  battery  recharging  system,  and 
the  data  unloading  system.  The  proposed  layout  of  the  trailer  will  be 
such  that  the  players  could  walk  in  one  door  of  the  trailer,  put  on  each 
of  the  required  pieces  of  equipment,  exit  out  the  other  door  of  the 
trailer,  enter  one  door  of  the  trailer,  be  issued  the  weapons,  and  then 
exit.  The  separate  weapons  trailer  is  used  to  provide  the  necessary 
security. 

Figure  27  shows  a  possible  deployment  of  the  three  trailers. 

The  area  bounded  by  the  trailers  will  be  lighted  by  flood  lights  attached 
to  the  trailers  and  will  also  be  serviced  by  a  public  address  system.  A 
verification  system  will  be  placed  as  shown  in  Figure  3,  outside  the 
weapons  trailer.  As  the  players  exit  the  trailer  they  would  stop  at  a 
designated  spot,  fire  their  weapon  at  a  sensor  target  verifying  their 
weapon,  and  then  their  sensors  would  be  verified  by  a  laser  associated 
with  the  target. 

The  preceding  outline  of  the  configuration  and  deployment  of 
t he  individual  trailers  is  preliminary  and  subject  to  change.  The 
concept  behind  each  of  the  trailers  should  not  change;  only  the  details 
of  the  equipment  placement  may  be  expected  to  change  pending  decision  on 
the  exact  trailers  to  be  used. 
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SECTION  III 


SOFTWARE  DEVELOPMENT 


3-1  INTRODUCTION 

2 

Several  tilings  have  been  done  in  defining  the  TNF  S  instrumen¬ 
tation  system  which  will  minimize  the  recurring  costs  of  software  develop¬ 
ment.  First,  whenever  possible,  vendor  supplied  software  is  used. 

Second,  all  software  is  produced  using  modular,  top-down  structured 
programming.  This  makes  the  software  traceable  and  flexible.  It  can  be 
easily  and  quickly  modified  as  the  situation  demands.  Finally,  the 
master  station  and  the  player  packs  share  a  common  instruction  set. 

This  commonality  is  true  at  both  the  coding  and  object  level.  This 
commonality  is  somewhat  unique  and  vastly  reduces  the  total  programming 
burden  as  well  as  providing  module  transportability.  Such  transporta¬ 
bility  is  only  moderately  achievable  using  High  Order  Languages  if  the 
object  code  compatibility  condition  is  not  met. 

3-1,1  Master  Station 

The  master  station  software  is  quite  straightforward,  although 
many  of  the  details  remain  to  be  worked  out.  As  shown  in  Figure  28,  the 
basic  master  station  consists  of  two  processors,  one  acting  as  a  concen¬ 
trator  for  the  communication  system.  This  dual-processor  system  will  be 
integrated  using  vendor-supplied,  commercially  available  interfaces. 

The  concentrator  will  handle  all  RF  system  related  processing  and  provide 
data  in  burst  mode  to  the  mala  controller  for  recording  and  display. 

All  software  for  the  concentrator  remains  to  be  developed,  but  will  be 
done  in  such  a  way  that,  in  the  event  of  a  catastrophic  failure,  it  can 
be  Loaded  in  main  controller  although  the  master  station  will  then 
operate  at  a  somewhat  reduced  efficiency. 

The  software  for  the  main  master  station  controller,  produced 
bv  Texas  Instruments,  will  run  under  the  T.T.'s  commercial  operating 
sv: : em  (DX10).  This  will  reduce  the  effort  significantly  compared  to 
stand-alone  software  production. 
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The  basic  hardware  for  both  the  master  station  controller  and 
the  RF  concentrator  will  be  identical,  thus  significantly  reducing  the 


spare  parts  logistics. 

3-1.2  Player  Software 

The  player  pack  software  is  somewhat  unusual  for  a  microprocessor- 
based  instrumentation.  The  extreme  flexibility  requirements  dictate 
that  an  operating  system  philosophy  be  employed.  The  operating  system 
will  be  highly  modular  to  allow  easy  reconfiguration  of  the  specific 
hardware  elements  and  must  isolate  the  control  of  these  hardware  elements 
so  that  data  transfers  can  occur  reliably,  independent  of  the  particular 
process  in  progress.  Furthermore,  processes  must  be  prioritized.  This 
prioritization  must  occur  at  two  levels:  (1)  data  transfers  with 
peripheral  devices  must  be  prioritized  on  the  basis  of  both  the  transi¬ 
tory  nature  of  the  data  and  its  prospective  importance  to  the  player  in 
an  operational  scenario.  For  example,  laser  illumination  data  is 
operationally  more  important  than  position  data  since  it  could  result  in 
a  simulated  player  casualty,  and  (2)  computational  processes  must  be 
prioritized  on  the  basis  of  relative  operational  importance. 

These  requirements  lead  to  the  following  conclusions  concerning 
player  pack  software:  (1)  data  transfers  to  peripherals  must  be  driven 
by  prioritized  interrupts,  (2)  normal  computational  processes  (tasks) 
are  prioritized  and  execute  under  control  of  the  operating  system,  (3) 
tasks  communicate  with  peripherals  via  supervisor  calls  to  operating 
svstem  modules  which  actually  handle  the  data  transfer,  and  (4)  CPU 
resources  are  allocated  to  the  most  important  pending  task. 

Thus,  the  player  software  is  divisible  into  two  modular  cate¬ 
gories:  (1)  the  Executive  Control  System  (ECS)  which  is  a  prioritized, 

interrupt-driven,  multitasking  operating  system,  and  (2)  all  computational 
modules  or  tasks. 

The  Executive  Control  System  consists  of  four  major  functional 
elements  with  an  optional  fifth  element.  As  shown  in  Figure  29,  these 
are:  (1)  the  task  scheduler  which  determines  which  task  is  currently  to 
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be  executed,  (2)  the  memory  manager  which  allocates  blocks  of  memory  as 
required,  (3)  the  1/0  Supervisor  which  maintains  the  communications 
between  tasks  and  peripherals,  (A)  the  task  control  supervisor  through 
which  tasks  can  initiate  other  tasks,  etc.,  and  (5)  file  management  for 
handling  random  access  files  on  the  mass  storage  device. 

The  tasks  which  execute  under  the  auspices  of  ECS  determine 
the  functional  role  of  the  player  pack.  Tasks  can  be  modularly  added  or 
deleted  without  affecting  the  remainder  of  ECS.  Such  processes  as  Real- 
Time  Casualty  Assessment  (RTCA) ,  Position  Location  (PL)  ,  and  RF  communi¬ 
cations  are  performed  by  tasks. 

3-1.2. 1  The  Task  Scheduler 

The  Task  Scheduler  uses  a  round-robin  algorithm  to  execute 
tasks  resident  on  four  priority  queues.  This  algorithm  assures  both 
that  the  highest  priority  tasks  receive  the  greatest  amount  of  CPU  time 
and  that  low  priority  tasks  are  not  totally  locked  out. 

3-1. 2. 2  Memory  Management 

To  minimize  the  amount  of  physical  memory  required  in  the 
player  pack,  temporary  buffers  and  ECS  tables  operate  in  dynamically 
allocated  memory.  This  technique  makes  memory  available  where  and  when 
it  is  needed.  The  memory  manager  is  responsible  for  keeping  track  of 
the  dynamic  memory  and  allocating  it  as  required. 

3-1. 2. 3  The  Input/Output  Supervisor 

The  I/O  supervisor  consists  of  a  system  core  processing  module 
and  a  group  of  special  purpose  modules  (Device  Service  Routines  or 
DSRs) .  Each  DSR  handles  the  specific  I/O  process  for  a  single  peripheral 
device  and  interfaces  to  ECS  through  a  rigidly  defined  protocol.  Adding 
a  peripheral  to  ECS  is  done  by  simply  installing  the  DSR  into  the  modular 
list  of  the  I/O  supervisor. 

3-1. 2. A  Task  Control  Supervisor 

The  Task  Control  Supervisor  handles  the  processes  which  affect 
task  scheduling  and  execution.  Tasks  may  cause  other  tasks  to  go  into 
execution,  suspend  their  own  execution,  generate  time  delays,  and  other 
functions  required  in  a  multitasking  environment. 
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3-1. 2. 5  File  Management 

The  file  management  module  is  optional.  Its  use  is  restricted 
to  player  packs  using  magnetic  bubble  memories  for  mass  storage.  It 
provides  the  bookkeeping  and  control  functions  for  implementing  random 
access  files,  both  temporary  and  permanent. 

3-2  TASK  SOFTWARE 


Because  tasks  are  isolated  from  the  actual  system  hardware  by 
the  I/O  supervisor  they  can  be  written  without  the  need  to  attend  to  the 
details  of  data  transfer  processes.  In  fact,  the  run-time  environment 
of  a  task  executing  under  ECS  is  nearly  identical  to  that  of  a  commercial 
minicomputer.  This  condition  vastly  simplifies  task  software  production 
and  very  definitely  modularizes  the  total  task  complement.  Tasks  can  be 
added  or  deleted  at  will  with  no  impact  on  the  remainder  of  the  soft¬ 
ware.  Figure  30  shows  the  communication  paths  between  Tasks  and  ECS. 

No  effort  has  been  expended  to  date  which  is  specifically  devoted  to  any 
of  the  tasks,  however,  a  great  deal  of  preliminary  work  has  been  done; 
especially  in  the  area  of  algorithms  for  position  location  and  RTCA. 

Some  of  the  tasks  already  identified  are  described  below.  There  will, 
inevitably,  be  many  additions  as  process  details  are  worked  out. 

3-2.1  Real-time  Casualty  Assessment 

RTCA  is  the  primary  task  in  the  player  pack  system.  It  is 
here  that  a  player's  miss/wound/kill  status  is  determined  subsequent  to 
a  weapon  simulator  engagement.  RTCA  will  be  handled  by  a  set  of  tasks 
in  final  form.  The  first  obvious  division  is  to  provide  separate  tasks 
to  handle  direct  fire  weapons  and  indirect  fire  or  area  weapons. 

3-2. 1.1  Direct  Fire  RTCA 

For  direct  fire  weapons  a  laser  simulator  is  used.  Parameters 
of  the  casualty  assessment  are:  slant  range,  weapon  type,  body  area 
illuminated,  firer  posture,  firer  marksmanship,  number  of  previous 
wounds,  and  round  type.  Algorithms  based  on  many  of  these  parameters 


84 


have  been  developed  at  BDM  previously,  although  modifications  will  be 
required  to  incorporate  all  of  them.  Monte  Carlo  techniques  will  be 
used  to  "force-fit"  the  algorithm  to  match  existing  AMSAA  data  over  a 
statistically  large  sample.  However,  responsibility  for  the  intimate 
details  of  the  RTCA  algorithm  properly  fall  with  the  T&E  contractor 
since  test  analysis  is  highly  dependent  on  the  precise  details  of  the 
calculation. 

3-2. 1.2  Indirect  Fire  RTCA 

Indirect  fire  weapons  are  fundamentally  different  from  direct 
fire  weapons  and  must  be  treated  differently.  Here  the  significant  data 
are  range  to  the  projectile  impact  point,  projectile  type  (hand  grenade, 
etc.),  and  player  shielding.  While  sufficient  information  is  available 
to  allow  development  of  the  computational  aspects  of  this  task,  adequate 
simulators  to  provide  input  data  have  not  yet  been  developed.  Conse¬ 
quently,  this  task  will  remain  in  limbo  pending  further  development  of 
the  simulators. 

3-2. 1.3  Position  Location 

Player  position  will  be  determined  from  either  LORAN-C  data  or 
from  transponder  data.  Baseline  data  is  currently  being  generated  to 
permit  algorithm  development  to  proceed. 

3-2.1. A  RF  Communications 

The  RF  communications  task  interprets  incoming  RF  messages 
from  the  master  station,  formulates  a  response,  and  transmits  it. 

3-3  DEVICE  SERVICE  ROUTINES  (DSR) 


Each  hardware  device  in  the  player  pack  either  supplies  data 

to  or  requires  data  from  the  computer.  Operating  on  the  data,  either  to 

generate  it  or  reduce  it,  is  the  function  of  various  tasks.  The  actual 

transfer  of  data  to/from  the  hardware  is  handled  by  the  DSRs.  The  DSRs 

interface  to  ECS  through  a  rigidly  defined  software  protocol  and  perform 

all  required  interrupt  processing  and  data  transfers  with  the  appropriate 

hardware.  Each  peripheral  device  requires  a  DSR.  Peripherals  and  DSRs 

2 

identified  as  required  for  TNF  S  are  shown  in  Figure  28. 
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SECTION  IV 


INSTRUMENTATION  DEVELOPMENT  PLAN 

4-1  INTRODUCTION 

2 

The  TNF  S“  Instrumentation  will  be  the  primary  test  and  evalua¬ 
tion  tool  to  be  used  in  evaluating  proposed  improvements  to  the  surviva¬ 
bility  and  security  of  the  Theater  Nuclear  Forces.  The  instrumentation 
will  allow  free-play,  force-on-force  testing  with  real  time  casualty 
assessment  and  facilitates  the  two-sided,  free-flowing  operational 
scenario  necessary  to  realistically  evaluate  the  effectiveness  of  the 
proposed  improvements. 

The  development  began  in  December,  1978  with  BDM  acting  as  the 
integrating  contractor.  The  International  Laser  System,  Orlando, 

Florida,  was  awarded  a  contract  in  March,  1979  to  develop  the  weapons 
effects  subsystem  and  VEGA  Precision,  Vienna,  Virginia,  was  awarded  a 
contract  in  September,  1979  to  develop  the  RF  transceiver  subsystem. 
Coordination  with  several  I.ORAN-C  manufacturers  took  place  throughout 
1979  and  evaluation  of  LORAN-C  for  use  as  a  position  location  subsystem 
is  continuing  into  December,  1979. 

The  basic  design  philosophy  utilized  during  the  engineering 
development  phase  is  centered  around  a  system  that  is  to  be  modular, 
flexible,  and  easily  expandable.  The  backbone  or  permanent  position  of 
the  player  pack  consists  of  a  microcomputer,  power  supply,  and  connectors 
to  the  various  functional  elements.  Because  the  unit  is  computer  con¬ 
trolled,  with  each  player  function  acting  as  peripheral  devices,  it  will 
be  truly  flexible  and  expandable. 

A  modular  approach  was  utilized  in  the  design  of  the  player 
functional  elements.  This  will  allow  hardware  and  software  tasks  to  be 
performed  in  parallel  under  this  proposed  effort.  The  various  functional 
elements  are:  (1)  weapon  simulation,  (2)  weapon  detection,  (3)  data 
logging,  (4)  position  location,  (5)  cueing,  (6)  direct  ranging,  (7)  RF 
communications,  and  (8)  hardware/software  development  system  and  the 
field  O&M  and  quick-look  systems. 


_/ 
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4-2 


DEVELOPMENT  SCHEDULE  AND  TASKS 


The  Instrumentation  Plan  follows  a  primary  or  baseline  approach, 
using  LORAN-C  for  the  initial  position  location  system.  This  approach 
minimizes  both  schedule  and  cost  risk  factors  and  will  provide  for  early 
field  testing.  The  proposed  effort  also  identified  a  parallel  task  to 
improve  the  position  location  accuracy,  utilizing  transponder  techniques. 

The  packaging  concept  is  designed  to  provide  for  a  direct  replacement  of 
the  hardware  units.  Figure  31  illustrates  the  overall  development 
schedule  and  Figure  32  shows  the  key  program  milestones  for  FY  1980. 

Parallel  development  of  the  functional  elements  was  accomplished 
during  the  first  year's  effort,  with  laboratory  demonstrations  performed 
during  the  fourth  quarter  of  FY  1979  and  the  first  and  second  quarter  of 
FY  1980.  Figure  33  illustrates  the  systems  integration  and  design 
efforts  to  be  performed. 

A  key  factor  in  meeting  the  overall  schedule  was  the  timely 
acquisition  of  the  Instrumentation  Development  System.  This  system  was 
required  at  an  early  date  to  allow  parallel  efforts  in  both  hardware  and 
software  development.  It  must,  at  a  minimum,  be  configured  exactly  as 
the  master  station  controller.  To  reduce  recurring  labor  costs,  it 
should  be  somewhat  larger  in  terms  of  both  main  memory  and  disk  capacity. 

The  system  was  specified  in  September  of  1978  and  was  never  procurred 
for  several  reasons.  The  original  system  was  configured  to  handle  the 
additional  task  of  data  base  management  which  is  no  longer  required. 
Consequently  it  can  be  reduced  in  size  and  cost,  nonetheless  the  requirement 
for  it  is  still  valid.  Specification  will  be  submitted  to  FCDNA  in 
December,  1979  as  to  its  final  configuration. 

4-3  RELATED  EFFORTS  FOR  FUTURE  PLANNING 

There  are  several  categories  of  instrumentation-related  efforts 
which  falL  well  beyond  the  scope  of  the  current  development  program. 
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These  deal  primarily  with  the  long-term  operations,  maintenance,  and  the 
evolutionary  aspects  of  the  instrumentation  and  with  test-specific  require¬ 
ments.  To  properly  address  these  issues  requires  timely  identification 

and  funding  of  the  required  efforts.  The  following  paragraphs  illustrate 

2 

those  efforts  that  will  be  needed  throughout  the  lifetime  of  the  TNF  S 
program. 

4-3.1  Continued  Development 

Continued  development  refers  primarily  to  the  long-term 
evolutionary  aspects  of  the  instrumentation.  As  new  weapon  systems  are 
fielded,  new  hardware  and/or  software  modules  must  be  added  to  the  plaver- 
pack  to  simulate  these  systems.  Other  additions  such  as  flyout  models, 
etc.  will  be  required  as  conditions  and  equipment  (both  threat  and 
friendly)  evolve. 

Also  to  be  considered  here  is  incorporation  of  advances  in 
technology  which  would  allow  reductions  in  size,  power,  and  weight  of 
the  manpack  unit. 

4-3.2  Issue-related  Instrumentation 

This  category  contains  all  the  "unknowns."  Special  equipment 
required  to  gather  unique  types  of  data  —  unknown  now,  to  be  identified 
as  test  planning  proceeds.  Such  things  as  instrumented  umpire  equipment, 
closed-circuit  TV,  etc.  fall  into  this  category.  Other  developments 
include  requirements  for  indirect  fire  simulators  and  smoke /f lash/bang 
cueing  devices.  The  question  here  is  not  IF  such  work  will  have  to  be 
done  but  WHEN. 

4-3.3  F ield  Test  Support 

A  certain  level  of  engineering  support  will  be  required  on  a 
continuing  basis  for  all  tests  to  aid  in  set-up,  deployment,  data  acqui¬ 
sition,  maintenance,  etc.  This  is  particularly  true  when  the  instru¬ 
mentation  system  is  moved  to  a  new  site.  The  manpower  requirements  are 
partially  dependent  on  the  number  of  players  to  be  involved  in  a  test. 
Figure  33  shows  estimates  of  these  requirements. 
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Typical  instrumentation  personnel  utilization. 
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4-4 


DEPOT  MAINTENANCE 


* 


The  rationale  behind  the  master  station  maintenance  facility 
is  to  provide  module-level  fault  detection  capability  for  player  pack 
modules  and  repair  capability  for  low-level  items  such  as  connectors, 
batteries,  etc.  To  provide  board-level  repair  facilities  in  the  master 
stations  would  drastically  increase  their  cost.  However,  this  approach 
presupposes  that  a  depot  maintenance  facility  with  such  capability 
exists.  Thus,  faulty  equipment  from  several  locations  can  be  sent  to  a 
single  facility  for  detailed  fault  analysis  and  repair.  Such  a  facility 
should  also  be  capable  of  performing  remote  maintenance  (both  hardware 
and  software)  on  the  mobile  master  station.  The  equipment  required  for 
a  depot  maintenance  facility  is  precisely  that  required  for  initial 
instrumentation  development,  continued  development,  and  issue-related 
instrumentation  development  as  addressed  in  previous  paragraphs.  The 
Instrumentation  Development  System,  described  earlier,  would  provide  the 
non-recurring  core  of  such  a  facility.  The  only  recurring  costs  would 
be  those  of  staffing  and  operating  it. 
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APPENDIX  A 
GLOSSARY 

A/D  -  Analog  to  Digital.  An  electronic  means  of  converting 

a  voltage  continuous  with  respect  to  time  into  a  number 
represented  by  a  discrete  set  of  voltage  states.  A 
continuous  voltage  is  converted  into  a  discrete  digital 
word  or  number. 

APU  -  Arithmetic  Processing  Unit.  Provides  floating  point 

arithmetic,  trigonometric  functions,  etc.,  on  a  single 
integrated  circuit.  Very  high  speed. 

BIT  -  Unit  of  information  equal  to  one  binary  decision, 

represented  by  a  one  or  a  zero. 

BITE  -  Built-In  Test  and  Evaluation.  Self-test  circuitry  built 

into  an  electronics  module  which  allows  functional  testing 
of  the  module  during  its  operation. 

BOOT  -  A  software  routine  whose  first  few  instructions  are 

sufficient  to  cause  the  rest  of  the  routine  to  be 
brought  into  the  computer  from  an  input  device. 

BUFFER  -  A  sequence  of  locations  in  the  computer's  memory  which 

are  used  for  temporary  storage  of  data.  Used  heavily 
when  transferring  data  from  the  computer  to  an  external 
device. 

BYTE  -  8-bit  packet  of  digital  computer  data. 

2 

CIU  -  Communications  Interface  Unit.  A  module  in  the  TNF  S 

player  pack  which  handles  data  conversion  for  both  the 
laser  weapon  simulator  and  RF  communications. 

CMOS  -  Complementary  Metal  Oxide  Semiconductor.  Extremely  low- 

power  technology.  Only  a  limited  number  of  functional 
part  types  are  available.  Very  slow  operation  compared 
to  other  technologies. 
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Appendix  A 

CODE 

CPU 

CRU 


DMA 


DMAC 


DNA 

DSR 


DX10 

ECS 

EMF 

EPROM 

FET 

FIFO 


Glossary  (Continued) 

A  sequence  of  computer  instructions.  Equivalent  to 
"program. " 

Central  Processing  Unit.  In  a  microcomputer  this  refers 
to  the  microprocessor  component. 

Communications  Register  Unit.  A  serial  data  link  used  by 
the  9900  family  of  computers  to  communicate  with  devices 
external  to  the  CPU. 

Direct  Memory  Access.  The  process  of  transferring  informa¬ 
tion  from  one  area  of  a  computer  memory  to  another  without 
intervention  by  the  CPU.  It  is  orders  of  magnitude 
faster  than  CPU-controlled  transfers. 

Direct  Memory  Access  Controller.  A  single  integrated 
circuit  which,  once  initialized  by  the  CPU,  controls  the 
DMA  process. 

Defense  Nuclear  Agency. 

Device  Service  Routine.  A  software  routine  used  to  inter¬ 
face  a  device  to  the  ECS  software.  An  example  of  a  DSR 
would  be  the  software  needed  to  transfer  data  from  the 
computer  to  an  external  device  such  as  the  data  logger. 
Operating  system  for  TI990  Minicomputer. 

Executive  Control  System.  The  player  pack  microcomputer, 
including  hardware  and  software,  exclusive  of  the  functional 
hardware  modules. 

Electromotive  force  or  a  voltage. 

Eraseable  Programmable  Read  Only  Memory. 

Field  Effect  Transistor.  A  voltage  controlled  switch. 
First-In-First-Out  Memory.  A  single  integrated  circuit 
memory  stack  with  a  capacity  of  4  to  64  bytes.  Data  is 
entered  at  a  single  point  and  retrieved  from  a  single  point 
in  the  order  of  entry. 
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GFE 

GPS/ 

NAVSTAR 

ID 

IDF 


ILS 

i2l 

I/O 

INTERRUPT  - 

LOS 

LORAN 

Low-Power 
Schottky  - 


Government  Furnished  Equipment. 

Global  Positioning  System.  A  position  location  system 
based  on  the  use  of  synchronous  satellites. 

Identification  Code.  Used  to  identify  players,  weapons, 
and  weapon  types. 

Indirect  Fire.  Generic  term  referring  to  all  military 

weapons  except  those  used  in  a  point-to-point  mode,  such 

as  rifles.  Examples:  mortars,  artillery,  grenades, 

missies,  etc.  Usually  with  explosive  rounds. 

International  Laser  Systems,  Orlando,  Florida.  Awarded 

contract  by  DNA  for  the  Weapons  Effects  system. 

2 

Integrated  Injection  Logic.  The  I  L  logic  family  can  be 

2 

easily  interfaced  to  other  logic  families.  I  L  is  a  new 
technology  with  high  circuit  density.  It  is  current  driven 
rather  than  voltage  driven.  Low  power  technology. 
Input/Output.  Refers  to  the  generic  data  transfer  process. 
Usually  implies  communications  between  a  computer  and  its 
peripherals . 

A  signal  from  a  device  outside  the  microprocessor  which 
tells  the  microprocessor  that  the  device  is  requesting 
some  sort  of  service. 

Line  of  Sight.  Refers  to  weapons  which  are  usually 
sighted  on  the  target  (rifles,  etc.). 

Instrumentation  developed  for  the  purpose  of  determining 
time-correlated  fixed  and  dynamic  position  locations 
of  players. 

Same  as  Schottky  except  lower  power  and  slightly  slower 
in  speed. 
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Appendix  A.  Glossary  (Continued) 


Main  Frame 
Computer 


Micro¬ 
computer  - 


Micro- 
Processor  - 


Mini¬ 

computer 


The  largest  size  computer.  Usually  several  racks  in  size. 
Can  support  a  wide  variety  of  peripheral  devices.  Usually 
has  a  very  powerful  intruction  set.  Word  lengths  are 
usually  greater  than  32  bits  with  addressing  capabilities 
of  more  than  100K  bytes.  Very  fast  with  typically  less 
than  1  microsecond  average  instruction  execution  time. 

A  multi-chip  computer  which  includes  a  microprocessor, 
system  memory,  and  the  necessary  control  circuitry.  The 
system  memory  stores  the  programs  and  data  necessary  for 
the  particular  operation.  The  control  circuitry  interfaces 
the  microprocessor  to  the  other  system  components. 

Typically  fits  on  one  board. 

A  one-chip  processing  unit  which  contains  an  arithmetic/ 
logic  unit,  temporary  storage  registers,  and  timing  and 
control  circuitry.  Usually  has  a  word  length  of  16  bits 
or  less  and  an  addressing  capability  of  65K  bytes  or  less. 
Average  instruction  execution  time  is  on  the  order  of  1  to 
10  microseconds. 

An  upgraded  version  of  a  microcomputer  with  an  increase  in 
speed,  addressing  capability,  and  the  power  of  the  instruc¬ 
tion  set.  The  physical  size  is  considerably  larger  than 
that  of  a  microcomputer  —  typically  a  minicomputer  is 
mounted  in  a  rack.  A  minicomputer  is  usually  able  to 
communicate  with  a  large  number  of  peripheral  devices 
including  line  printers,  user  terminals,  and  disk  drives. 
Word  length  is  16  to  32  bits. 
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NMOS 

Operating 

System 

O&M 

PL 

PROM 

PSI 

QCB 

QUEUE 

RAM 

Real-Time 

Clock 
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Glossary  (Continued) 

N-channel  Metal  Oxide  Semiconductor.  NMOS  is  a  logic 
family  which  is  used  primarily  in  memory  applications. 

This  logic  family  has  a  fairly  high  density  while  using 
relatively  low  amounts  of  power. 

The  collection  of  software  modules  which  control  the 
allocation  of  the  resources  of  the  CPU  and  the  external 
devices . 

Operations  and  Maintenance. 

Position  Location. 

Programmable  Read  Only  Memory.  Memory  which  has  the 
ability  to  be  user  programmed.  Otherwise,  same  as  ROM. 
Programmable  Systems  Interface  provides  interrupts, 

I/O  ports  and  interval  timer  for  the  9900  System. 

Queue  Control  Block.  The  block  of  control  information 
used  to  store  queue  parameters.  The  information  in  a  QCB 
includes  pointers  to  the  first  and  last  object  in  the  list 
and  a  count  of  the  number  of  objects  in  the  list. 

A  linked  list  of  objects.  The  objects  can  be  added  to  and 
deleted  from  the  queue  with  relative  ease. 

Random  Access  Memory.  A  memory  which  can  be  read  from 
or  written  to  in  approximately  the  same  amount  of  time. 
Used  to  store  data  which  must  be  changed. 

Hardware  external  to  the  microprocessor  which  interrupts 
the  processor  on  a  periodic  basis.  The  real-time  clock 
(RTC)  can  be  used  by  the  computer's  operating  system  to 
implement  such  functions  as  time  slicing  and  time  of 
day  (TOD). 
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Re-entrant 

Code 


RF 

RFCIU 

ROM 


RTCA 


Schottky  - 

s2 

Sneak 

Path 


SCB 


Subroutine- 


Supervisor 

Call 


A  string  of  computer  instructions  which  is  designed  to 
be  used  by  several  calling  programs  at  the  same  time. 
Production  of  re-entrant  code  is  considerably  more  difficult 
than  writing  code  without  this  property. 

Radio  Frequency. 

Radio  Frequency  Communications  Interface  Unit. 

Read  Only  Memory.  A  memory  that  is  used  for  storage  of 
fixed  programs  or  data.  Retains  its  information  when  power 
is  turned  off.  Contents  cannot  be  altered.  Contents  set 
during  manufacturing. 

Real-Time  Casualty  Assessment.  A  computer  algorithm  which 
determines  the  probability  that  an  engaged  player  has  been 
killed. 

A  high-speed,  high-power  logic  family.  Easily  interfaced 
to  other  logic  families. 

Survivability  and  Security. 

A  possibly  unforeseen  "path"  between  software  modules. 

A  sneak  path  can  cause  severe  problems  in  the  software. 
Supervisor  Call  Block.  A  block  of  control  information  used 
when  accessing  a  device  service  routine. 

A  section  of  code  which  is  used  frequently  can  be  placed 
into  a  form  such  that  any  program  which  needs  the  service 
can  "call"  the  subroutine.  The  use  of  subroutines  can 
result  in  a  considerable  savings  in  memory  requirements. 

A  mechanism  by  which  a  task  can  request  a  service  that 
the  operating  system  can  provide.  An  example  of  such  a 
service  might  be  a  request  to  transfer  data  between  the 
computer  and  an  external  device. 
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Appendix  A.  Glossary  (Concluded) 


Task 


Task 

Scheduler  - 


TI 

Time 

Slicing 


TNF 
TNF  S2 
TSB 


TTL 

USAFE 

VMOS 


WECIU 


A  computer  program  which  performs  some  computational 

2 

function.  An  example  of  a  task  in  the  TNF  S  player 
pack  application  would  be  the  Real-Time  Casualty 
Assessment  (RTCA)  Calculation. 

The  software  module  which  determines  which  tasks  in  the 
system  should  become  active  and  at  whiUi  priority  they 
should  execute. 

Texas  Instruments. 

The  mechanism  by  which  each  active  task  in  the  system  is 
given  "slices"  of  a  predetermined  length  of  time  to  execute. 
Any  given  task  may  take  several  "time  slices"  to  run  to 
completion.  The  end  of  a  slice  is  signified  by  an  interrupt 
to  the  microprocessor  at  which  time  another  task  is  allowed 
to  become  active  and  the  first  task  is  temporarily  suspended. 
Allows  tasks  of  equal  importance  to  execute  "concurrently." 
Theater  Nuclear  Force. 

Theater  Nuclear  Force  Survivability  and  Security. 

Task  Status  Block.  The  block  of  control  information  used 
to  store  parameters  about  a  particular  task.  The  TSBs  are 
linked  together  to  form  queues. 

Transistor-Transistor  Logic.  A  logic  family  characterized 
by  its  input/output  features.  Very  commonly  used. 

United  States  Air  Force  in  Europe. 

Vertical  Metal  Oxide  Semiconductor.  VMOS  is  a  new 
technology  logic  family  similar  to  the  NMOS  logic  family, 
except  that  VMOS  is  slightly  faster  but  with  lower 
density  and  lower  power  requirements. 

Weapon  Effects  Communication  Interface  Unit. 
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